Date: Mon, 03 Apr 2000 00:33:54 +0200 From: Poul-Henning Kamp <phk@critter.freebsd.dk> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: 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: <16382.954714834@critter.freebsd.dk> In-Reply-To: Your message of "Sun, 02 Apr 2000 15:23:46 PDT." <200004022223.PAA51020@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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. -- Poul-Henning Kamp FreeBSD coreteam member phk@FreeBSD.ORG "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! 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?16382.954714834>