Date: Fri, 9 Feb 2001 10:59:43 +0600 (ALMT) From: Boris Popov <bp@butya.kz> To: Bosko Milekic <bmilekic@technokratis.com> Cc: freebsd-arch@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Subject: Re: Sequential mbuf read/write extensions Message-ID: <Pine.BSF.4.21.0102091054490.25955-100000@lion.butya.kz> In-Reply-To: <001301c09245$b7400a00$1f90c918@jehovah>
next in thread | previous in thread | raw e-mail | index | archive | help
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 additional function that > will simply wrap the call to m_getm() and flush properly for it if it > fails (EXACTLY like your code snippet above). Ok, I think the (a) is a right way. There is no point to hold partially allocated mbuf chain. And function should return error code, not a pointer. > I'll gladly settle for either, but if we do go with (b), then the > m_freem() should be changed to an m_free(), as it reflects the fact > that we are only freeing the one mbuf and we should document this > behavior, certainly. If you want, I'll roll up a diff in a few days > (once I get what is presently dragging in my "commit this" queue out) > and commit it. If you prefer to do this yourself, then feel free. :-) Yes, I would appreciate your help on it. -- Boris Popov http://www.butya.kz/~bp/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0102091054490.25955-100000>