Date: Tue, 24 Feb 1998 11:41:48 +1030 From: Greg Lehey <grog@lemis.com> To: Mike Smith <mike@smith.net.au> Cc: "Justin T. Gibbs" <gibbs@plutotech.com>, hackers@FreeBSD.ORG Subject: Re: New SoftUpdates test kit Message-ID: <19980224114148.26366@freebie.lemis.com> In-Reply-To: <199802240102.RAA13122@dingo.cdrom.com>; from Mike Smith on Mon, Feb 23, 1998 at 05:02:07PM -0800 References: <19980224112304.63148@freebie.lemis.com> <199802240102.RAA13122@dingo.cdrom.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 23 February 1998 at 17:02:07 -0800, Mike Smith wrote: >> Wouldn't it make more sense to pass around an extended buf structure, >> as ccd and vinum do? Put the buf at the start, and you can pass it to >> all the routines that normally hand buf structures: > > No. You can't do this in a device driver - you're handed a buf by > someone else, and you give it back when you're done. Ah, yes, I'd forgotten the normal case :-) I need to allocate my own, because one high-level request can potentially spawn many low-level requests. > The problem is that the connection (in the wfd driver) between being > given the buf and handing it back involves passing the buf pointer to > someone else. > > To do this with a wrapper as you propose would involve copying the buf > into the wrapper and then out again. Bleagh. And you'd still have to > manage memory for the wrappers. Bleagh again. Right. In my case, of course, I'm forced to allocate new struct buf *s. Fortunately, since any transfer involves a contiguous fraction of the original request, I can just set bp->b_data to point into the b_data of the original buf, so the copying is of relatively small quantities. > The real killer is that there's no universal fragmenting layer sitting > on top of device drivers. Another mark for the SLICE stuff. Yup, when I have the first cut finished, I'll take a look at that. Greg To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19980224114148.26366>