From owner-cvs-all Sun Apr 2 16:30: 1 2000 Delivered-To: cvs-all@freebsd.org Received: from freebie.lemis.com (freebie.lemis.com [192.109.197.137]) by hub.freebsd.org (Postfix) with ESMTP id 0932537BA8E; Sun, 2 Apr 2000 16:29:55 -0700 (PDT) (envelope-from grog@freebie.lemis.com) Received: (from grog@localhost) by freebie.lemis.com (8.9.3/8.9.0) id IAA42310; Mon, 3 Apr 2000 08:59:39 +0930 (CST) Date: Mon, 3 Apr 2000 08:59:39 +0930 From: Greg Lehey To: Poul-Henning Kamp Cc: Matthew Dillon , cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: More Danish axes (was: cvs commit: src/sys/kern subr_devstat.c src/sys/ufs/ufs ufs_disksubr.c src/sys/sys buf.h devicestat.h disklabel.h) Message-ID: <20000403085939.C42140@freebie.lemis.com> References: <200004022223.PAA51020@apollo.backplane.com> <16382.954714834@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre2i In-Reply-To: <16382.954714834@critter.freebsd.dk> WWW-Home-Page: http://www.lemis.com/~grog X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF 13 24 52 F8 6D A4 95 EF 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-cvs-all@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Monday, 3 April 2000 at 0:33:54 +0200, Poul-Henning Kamp wrote: > In message <200004022223.PAA51020@apollo.backplane.com>, Matthew Dillon writes: > >> b_data is integral to buffer cache KVA management & operation and >> should be in the main struct buf structure, not the bio structure. > > No, b_data is (currently) also a property of the I/O request. > > The "built in" bio in struct buf is sacred (since the buf is the "caller") > so these fields will not be mucked about with by lower code, but the > lower code will need to be able to allocate new struct bio's which > obviously need to have their own b_data so it can be different from > the parent struct bio. > > Think about striping for instance, you may need to split a bio into > several bios which have different b_data fields. > > Eventually, once this mechanical divorce is completed, the b_ macros > may be expanded if we decide that is better, that is all TBD. > > If we go your b_pages route, we need to revisit the "translating > bio drivers" aka vinum, vn and ccd anyway, and then decide how to > tackle all of this. > >> b_bufsize is also integral to buffer cache management and should also >> not be moved, just in case you are thinking of moving it. > > Drivers should not even think about this field so obviously I wouldn't > even dream about putting it in bio. I'm not going to take either side, but I'd like to observe that this sort of discussion should have happened *before* committing. Greg -- Finger grog@lemis.com for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message