From owner-freebsd-hackers Mon Feb 23 16:47:32 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA00632 for freebsd-hackers-outgoing; Mon, 23 Feb 1998 16:47:32 -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 QAA00621 for ; Mon, 23 Feb 1998 16:47:20 -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 LAA08868; Tue, 24 Feb 1998 11:17:16 +1030 (CST) Received: (from grog@localhost) by freebie.lemis.com (8.8.8/8.8.7) id LAA13492; Tue, 24 Feb 1998 11:17:15 +1030 (CST) (envelope-from grog) Message-ID: <19980224111714.53585@freebie.lemis.com> Date: Tue, 24 Feb 1998 11:17:14 +1030 From: Greg Lehey To: "Justin T. Gibbs" Cc: hackers@FreeBSD.ORG Subject: Re: New SoftUpdates test kit References: <19980222175710.04357@freebie.lemis.com> <199802221804.LAA06017@narnia.plutotech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89i In-Reply-To: <199802221804.LAA06017@narnia.plutotech.com>; from Justin T. Gibbs on Sun, Feb 22, 1998 at 11:04:14AM -0700 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 Sun, 22 February 1998 at 11:04:14 -0700, Justin T. Gibbs wrote: >> 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: > > It has been discussed before that b_driver* should go away. The > CAM SCSI layer does not use these fields which means that the last > reference in our code is going away. Please don't add another > instance. Struct bufs are pervasive and keeping their size small > enough to be efficiently allocated is important. I'd have to go > look to see how close we are to a power of two in size right now, Or you could read my original message. 292 bytes. That's a long way whichever way you look at it. > but even if removing these fields doesn't shrink us down a malloc > bucket size, it will give us room to add things like pointers for > buffer chaining for larger than 64k I/O requests. Aren't 220 bytes enough? The original reason for me wanting to use this method seems to be based on misinformation. The only good documentation I have for buf(9) is from System V, where things are surprisingly similar. One big difference, though, is the way they should be allocated: Do not depend on the size of the buf structure when writing a driver (or any other module which needs binary compatibility). In particular, this means you must only allocate buf structures using DDI/DKI routines (for example, getrbuf). Static allocations are not allowed. I was having trouble in that area with my driver at the time, and I thought that a similar restriction might apply in BSD. Since then, I've found the problem, and the driver is running. Greg To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message