From owner-freebsd-hackers Sun Feb 22 00:02:46 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id AAA01520 for freebsd-hackers-outgoing; Sun, 22 Feb 1998 00:02:46 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from allegro.lemis.com (allegro.lemis.com [192.109.197.134]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id AAA01474 for ; Sun, 22 Feb 1998 00:02:38 -0800 (PST) (envelope-from grog@lemis.com) Received: from freebie.lemis.com (freebie.lemis.com [192.109.197.137]) by allegro.lemis.com (8.8.7/8.8.5) with ESMTP id SAA06591; Sun, 22 Feb 1998 18:32:34 +1030 (CST) Received: (from grog@localhost) by freebie.lemis.com (8.8.8/8.8.7) id SAA04891; Sun, 22 Feb 1998 18:32:33 +1030 (CST) (envelope-from grog) Message-ID: <19980222183233.41134@freebie.lemis.com> Date: Sun, 22 Feb 1998 18:32:33 +1030 From: Greg Lehey To: Mike Smith Cc: FreeBSD Hackers Subject: Re: New SoftUpdates test kit References: <19980222175710.04357@freebie.lemis.com> <199802220738.XAA06227@dingo.cdrom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89i In-Reply-To: <199802220738.XAA06227@dingo.cdrom.com>; from Mike Smith on Sat, Feb 21, 1998 at 11:38:57PM -0800 WWW-Home-Page: http://www.lemis.com/~grog Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-41-739-7062 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, 21 February 1998 at 23:38:57 -0800, Mike Smith wrote: >>> Could you chain these headers off the private fields at the end of the >>> buf structure, or is the feature set there too small? >> >> Hmmm. Sometimes it pays to RTFM. No, wait, there is no FM. OK, RTFS >> then. > > 8/ > >>> (NB. the wfd driver already uses one of these, it not being terribly >>> clear to me at the time who they were really for use by.) >> >> Well, they're used in scsi_ioctl.c and wfd.c, and that's the only >> place I've been able to find them. But it's a good idea, and it might >> be the way to save the ccd driver if that's what's eating it. > > The reason I asked is that if you depend on the extra state that you use > being preserved despite you passing the bufs out to other drivers, it > might pay to impose some sort of policy on which of the fields are > available for what usage. > > Of course, if vinum is at the top of the food chain and only uses the > private data internally, then you win. Good point. It passes them on to a disk driver. Theoretically, I suppose, that could be wfd, though I can't think who'd want to use it that way. Yes, you're right. We need to think about this more carefully. I'm following up to -hackers, where maybe this discussion should have been all along. To summarize for those who haven't seen this before: Julian Elischer has provided some patches to -CURRENT for Kirk McKusick's soft updates. We''re currently testing them, and have found a few bugs which Julian's looking at. One of these bugs concerns CCD, which crashes. Kirk has expressed an opinion that the buffer headers aren't initialized correctly. He's out of town (whatever that may mean) for a week, so we may not find out until then. In the meantime, I commented on the fact that ccd and my new volume driver, vinum, both use extended buf structures which aren't allocated in the normal way, and that maybe this is the problem. Mike then suggested (above) that the extensions could be chained off the pointers b_driver1 and b_driver2, both claimed to be "for private use by the driver". This is where we get to the top of this message. Mike, back to the discussion of policy. vinum needs some way to associate the buffer returned to the b_iodone function with its internal requests. CCD does this by including the buffer header in the internal request. The obvious alternative is to use one of b_driver[12] to point to the other information. The trouble is that scsi_strategy seems to use both of them. Consider a few possibilities: 1. Dodge around the usage. It seems to be related to ioctls, which are (so far :-) never issued by vinum. 2. Modify the SCSI code to only use one of these pointers. 3. Add additional pointers. With a current length of 292 bytes, another pointer or two might not make a big difference. Greg To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message