Date: Mon, 3 Apr 2000 08:59:39 +0930 From: Greg Lehey <grog@lemis.com> To: Poul-Henning Kamp <phk@critter.freebsd.dk> Cc: Matthew Dillon <dillon@apollo.backplane.com>, 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> In-Reply-To: <16382.954714834@critter.freebsd.dk> References: <200004022223.PAA51020@apollo.backplane.com> <16382.954714834@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20000403085939.C42140>