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
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:
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
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
