Date: Mon, 03 Apr 2000 01:52:27 +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: <16853.954719547@critter.freebsd.dk> In-Reply-To: Your message of "Sun, 02 Apr 2000 16:26:37 PDT." <200004022326.QAA51447@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <200004022326.QAA51447@apollo.backplane.com>, Matthew Dillon writes: >: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. > > No it isn't. b_data is the property of the buffer cache. If you > screw with it, you blow up the buffer cache. Any device driver that > screws with it must restore it prior to reentering the buffer cache > code. > > Several devices drivers mess with b_data ... but they really shouldn't. > Just because they do is no justification to move b_data into the bio. > > If you want you can duplicate b_data ... that is, have the buffer cache > managed KVA be a field in struct buf and copy it into a new field in the > bio which the device drivers use (and get rid of the save field that > the device drivers currently use to save/restore b_data). But that isn't > what you've done. Matt, lets discuss this when you have actually examined the code. -- 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?16853.954719547>