From owner-freebsd-net Wed Jun 28 8:41:33 2000 Delivered-To: freebsd-net@freebsd.org Received: from etinc.com (et-gw.etinc.com [207.252.1.2]) by hub.freebsd.org (Postfix) with ESMTP id A48DE37BA77; Wed, 28 Jun 2000 08:41:27 -0700 (PDT) (envelope-from dennis@etinc.com) Received: from dbsys (dbsys.etinc.com [207.252.1.18]) by etinc.com (8.9.3/8.9.3) with SMTP id LAA23490; Wed, 28 Jun 2000 11:40:47 -0400 (EDT) Message-Id: <200006281540.LAA23490@etinc.com> X-Sender: dennis@etinc.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Wed, 28 Jun 2000 11:49:27 -0400 To: Andrew Gallatin , Bosko Milekic From: Dennis Subject: Re: mbuf re-write(s): v 0.2: request-for-comments Cc: freebsd-hackers@FreeBSD.ORG, freebsd-net@FreeBSD.ORG In-Reply-To: <14681.63578.312644.776689@grasshopper.cs.duke.edu> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org 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