Hello,
Well, I've tried to take into account most of the suggestions and
placed an updated versions of files to http://www.butya.kz/~bp/mbuf/
If no serious problems will be found I would like to commit this
on next week (this version of functions included in the upcoming
In message <[EMAIL PROTECTED]>, Boris Popo
v writes:
> No, in the current implementation mb_get* functions will work
>properly. But mb_put* will fail. This can be avoided by implementing
>alignment-safe set* macros (which can be written in two variants - first
>form is for aligned objects an
On Thu, 8 Feb 2001, Bosko Milekic wrote:
> any case, if we do move this to uipc_mbuf.c, we need to do one of the
> following:
>
> (a) make m_getm() free what it allocated in previous loop iterations
> before it failed (as described above) or
>
> (b) leave m_getm() the way it is BUT write an add
Boris Popov wrote:
[...]
> > For this to work, though, m_getm() needs to be modified to free
all of
> > `top' chain if it can't get either a cluster or an mbuf. I don't
know
> > if this was intentional, but it seems to me that there is a subtle
> > problem in m_getm() as it is now:
> >
> > if (l
On Thu, 8 Feb 2001, Bosko Milekic wrote:
> in mb_init(), the m->m_pkthdr.rcvif = NULL; can be ommitted, as
> MGETHDR() will do that. The m->m_len = 0 should stay for now.
Ok.
> drivers that pre-allocate mbufs + clusters, they typically know the
> `count'), it turns out that it is cheape
On Thu, 8 Feb 2001, Ian Dowse wrote:
> It may be beneficial to use separate structs for the build and
> breakdown operations. The two cases have slightly different
> requirements: the mb_count field is only useful when building, and
> mb_pos is only strictly necessary when breaking down mbuf chai
Boris Popov wrote:
[...]
> Not exactly so. 'option LIBMBUF' will just connect the source file
> to kernel makefile. There is no need for any #ifdef's in the code.
Right. But I assume LIBMBUF will absolutely be needed if code that
uses the routines is compiled. What I just meant to say was:
In message <[EMAIL PROTECTED]>, Boris Popo
v writes:
> Before starting import process for smbfs, I would like to
>introduce new API which greatly simplifies process of packaging data into
>mbufs and fetching it back (in fact, similar API already presented in the
>tree, but it is private to t
> Before starting import process for smbfs, I would like to
> introduce new API which greatly simplifies process of packaging data into
> mbufs and fetching it back (in fact, similar API already presented in the
> tree, but it is private to the netncp code and it will be really nice to
> sha
On Wed, 7 Feb 2001, Boris Popov wrote:
BP>> Using 'word' and 'doubleword' is rather confusing (when speeking of words
BP>> I would think of 32 bit nowadays).
BP>
BP> Well, it depends. For me 'word', 'dword' and 'qword' are clear
BP>from the good old 8bit days :)
BP>
BP> If numbers in the
On Wed, 7 Feb 2001, Harti Brandt wrote:
> But, I would recommend to stick with the ususal naming of size dependend
> things, by appending a numeric suffix. Something like:
>
> int mb_get8(struct mbdata *mbp, u_int8_t *x);
> int mb_get16(struct mbdata *mbp, u_int16_t *x);
> int mb_get16le(stru
On Tue, 6 Feb 2001, Bosko Milekic wrote:
> > Since currently there isn't many consumers of this code I can
> > suggest to define an option LIBMBUF in the kernel configuration file
> and
> > add KLD libmbuf (with interface libmbuf), so kernel footprint will
> not be
>
> I am in favor of such
Looks nice, just what I needed two weeks ago and partly had
to implement myself :-)
But, I would recommend to stick with the ususal naming of size dependend
things, by appending a numeric suffix. Something like:
int mb_get8(struct mbdata *mbp, u_int8_t *x);
int mb_get16(struct mbdata *mbp, u_
Boris Popov wrote:
[...]
> Since currently there isn't many consumers of this code I can
> suggest to define an option LIBMBUF in the kernel configuration file
and
> add KLD libmbuf (with interface libmbuf), so kernel footprint will
not be
I am in favor of such an option on the condition th
On Tue, 6 Feb 2001, Alfred Perlstein wrote:
> Looks really cool, I can't get to http://www.butya.kz/~bp/mbuf/,
> but from the examples it looks very useful.
Sorry, server was brought down and I wasn't notified :(. It should
be ok now.
> I was wondering if you planned or already had an A
* Boris Popov <[EMAIL PROTECTED]> [010206 03:51] wrote:
> [Please trim CC list as necessary]
>
> Hello,
>
> Before starting import process for smbfs, I would like to
> introduce new API which greatly simplifies process of packaging data into
> mbufs and fetching it back (in fact, sim
[Please trim CC list as necessary]
Hello,
Before starting import process for smbfs, I would like to
introduce new API which greatly simplifies process of packaging data into
mbufs and fetching it back (in fact, similar API already presented in the
tree, but it is private to the n
17 matches
Mail list logo
