From owner-freebsd-hackers Wed Jun 28 14:48:18 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from panzer.kdm.org (panzer.kdm.org [216.160.178.169]) by hub.freebsd.org (Postfix) with ESMTP id 464C137C150; Wed, 28 Jun 2000 14:48:11 -0700 (PDT) (envelope-from ken@panzer.kdm.org) Received: (from ken@localhost) by panzer.kdm.org (8.9.3/8.9.1) id PAA53212; Wed, 28 Jun 2000 15:47:40 -0600 (MDT) (envelope-from ken) Date: Wed, 28 Jun 2000 15:47:40 -0600 From: "Kenneth D. Merry" To: Andrew Gallatin Cc: Dennis , Bosko Milekic , freebsd-hackers@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Subject: Re: mbuf re-write(s): v 0.2: request-for-comments Message-ID: <20000628154740.A53117@panzer.kdm.org> References: <14681.63578.312644.776689@grasshopper.cs.duke.edu> <200006281540.LAA23490@etinc.com> <14682.7393.3441.596574@grasshopper.cs.duke.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <14682.7393.3441.596574@grasshopper.cs.duke.edu>; from gallatin@cs.duke.edu on Wed, Jun 28, 2000 at 12:00:50PM -0400 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, Jun 28, 2000 at 12:00:50 -0400, Andrew Gallatin wrote: > Dennis writes: > > > > Its not really "wonderful" to those that have already implemented something > > using the old method. > > > > Speaking as somebody who maintains 3 out-of-tree network drivers & a > bunch of local code, all of which makes heavy use of external mbufs, I > certainly consider it to be "wonderful." > > > What version is this "patch" likely to find its way into the mainstream > > code (or will it), as its likely to break our drivers..... > > I presume that the reason it is being presented here is to collect > input. This input may influence the patch. I would imagine that it > would go into 5.0-CURRENT first. > > At any rate, you might not need to make changes to anything other than > your function prototypes, depending on how your ext_free and ext_ref > functions are implemented. He's basically changed the second arg of > those functions to take a void * which nobody else is going to look > at, so you can cast it to an int & use it as a simple counter or use > it as a pointer to a private data structure if you need more state. > Currently, that second arg is the ext_size, which was always pretty > useless (at least for me..). FWIW, I'm in favor of a pointer argument as well. The way I implemented it was actually with a third argument, instead of changing the int to void. i.e.: /* description of external storage mapped into mbuf, valid if M_EXT set */ struct m_ext { caddr_t ext_buf; /* start of buffer */ void (*ext_free) /* free routine if not the usual */ #ifdef EXTRA_MBUF_ARG __P((caddr_t, u_int, void *)); #else __P((caddr_t, u_int)); #endif u_int ext_size; /* size of buffer, for ext_free */ void (*ext_ref) /* add a reference to the ext object */ #ifdef EXTRA_MBUF_ARG __P((caddr_t, u_int, void *)); void *ext_arg; #else __P((caddr_t, u_int)); #endif }; I don't feel too strongly about it either way -- I suppose it's about the same amount of work to port older code. (I just put an ifdef in the sendfile code, which doesn't use the third argument in my tree.) Ken -- Kenneth Merry ken@kdm.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message