From owner-freebsd-arch Thu Feb 8 21: 0:20 2001 Delivered-To: freebsd-arch@freebsd.org Received: from relay.butya.kz (butya-gw.butya.kz [212.154.129.94]) by hub.freebsd.org (Postfix) with ESMTP id 91CB337B401; Thu, 8 Feb 2001 20:59:56 -0800 (PST) Received: by relay.butya.kz (Postfix, from userid 1000) id C8FF428695; Fri, 9 Feb 2001 10:59:43 +0600 (ALMT) Received: from localhost (localhost [127.0.0.1]) by relay.butya.kz (Postfix) with ESMTP id BE4992863E; Fri, 9 Feb 2001 10:59:43 +0600 (ALMT) Date: Fri, 9 Feb 2001 10:59:43 +0600 (ALMT) From: Boris Popov To: Bosko Milekic Cc: freebsd-arch@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Subject: Re: Sequential mbuf read/write extensions In-Reply-To: <001301c09245$b7400a00$1f90c918@jehovah> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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