Date: Wed, 28 Jun 2000 11:49:27 -0400 From: Dennis <dennis@etinc.com> To: Andrew Gallatin <gallatin@cs.duke.edu>, Bosko Milekic <bmilekic@dsuper.net> Cc: freebsd-hackers@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Subject: Re: mbuf re-write(s): v 0.2: request-for-comments Message-ID: <200006281540.LAA23490@etinc.com> In-Reply-To: <14681.63578.312644.776689@grasshopper.cs.duke.edu> References: <Pine.BSF.4.21.0006271756020.535-100000@jehovah.technokratis.com> <Pine.BSF.4.21.0006271756020.535-100000@jehovah.technokratis.com>
next in thread | previous in thread | raw e-mail | index | archive | help
At 10:09 AM 6/28/00 -0400, Andrew Gallatin wrote: > >Bosko Milekic writes: > > > This code includes all that was discussed in the previous Email, as > > well as a better/actually working external storage facility for clusters. > > Previously, it was very difficult to allocate external storage, attach it > > to the mbuf, _and_ as well maintain a reference counter for it, primarily > > due to the arguments that were taken by ext_free() and ext_buf(). These > > have been changed to have a new void * pointer passed in as the second > > argument (following the base address of the storage buffer). Also has > > been included a void * multi-purpose ext_args pointer in the m_ext > > struct, so the caller has much more flexibility now. In fact, the caller > > can now attach a "management" or "reference" structure to the m_ext > > struct via the ext_args pointer, and have it passed to his ext_free and > > ext_buf routines. Naturally, for dynamically sized malloc() external > >YES! This is wonderful news. > >I started coding device drivers on Digital UNIX and have long missed >this feature. I can't count the number of times I've gotten 90% of >the way through doing something with ext mubfs & thought to myself >"oh hell, now what am I going to do for an m_ext.ext_ref() function?" > >On a less enthusiastic note, the amount of whitespace changes make it >very difficult to eyeball your diff. Could you re-roll your diffs with >-b (to ignore your whitespace changes). Its not really "wonderful" to those that have already implemented something using the old method. What version is this "patch" likely to find its way into the mainstream code (or will it), as its likely to break our drivers..... Dennis To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200006281540.LAA23490>