From owner-cvs-all Sun Apr 2 16:26:45 2000 Delivered-To: cvs-all@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 2AABE37B57F; Sun, 2 Apr 2000 16:26:41 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id QAA51447; Sun, 2 Apr 2000 16:26:37 -0700 (PDT) (envelope-from dillon) Date: Sun, 2 Apr 2000 16:26:37 -0700 (PDT) From: Matthew Dillon Message-Id: <200004022326.QAA51447@apollo.backplane.com> To: Poul-Henning Kamp 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 References: <16382.954714834@critter.freebsd.dk> Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG : :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 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message