Date: Fri, 20 Aug 1999 08:44:51 +0930 From: Greg Lehey <grog@lemis.com> To: Poul-Henning Kamp <phk@critter.freebsd.dk> Cc: cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Splitting struct buf (was: cvs commit: src/sys/alpha/alpha diskslice_machdep.c src/sys/cam/scsi scsi_cd.c scsi_da.c src/sys/contrib/dev/fla fla.c src/sys/dev/ata ata-disk.c atapi-fd.c src/sys/dev/ccd ccd.c src/sys/dev/ida ida_disk.c src/sys/dev/vinum vinumdaemon.c vinuminterrupt.c ...) Message-ID: <19990820084451.A14964@freebie.lemis.com> In-Reply-To: <17378.934777240@critter.freebsd.dk>; from Poul-Henning Kamp on Mon, Aug 16, 1999 at 06:20:40AM %2B0200 References: <19990816084822.D799@freebie.lemis.com> <17378.934777240@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
On Monday, 16 August 1999 at 6:20:40 +0200, Poul-Henning Kamp wrote: > In message <19990816084822.D799@freebie.lemis.com>, Greg Lehey writes: >> On Sunday, 15 August 1999 at 8:22:31 +0200, Poul-Henning Kamp wrote: >>> >>>> These calls are internal to vinum. Why should they go via BUF_STRATEGY? >>> >>> There are a number of things in the pipe line which makes use of the >>> fact that the BUF_STRATEGY is used throught, one of these is the >>> "struct ioreq" divorce from struct buf. >> >> Would you care to give us some details? At the moment, it seems >> unlikely to affect a driver in its internal doings. > > The details are what I've told you earlier: struct ioreq will be > isolated from the bulk of struct buf and BUF_STRATEGY is where > it will be taken out and passed to the driver. Am I the only person who's unhappy about the naming of these structs? For the benefit of those who don't know about it, phk is planning to split struct buf into two parts: one (which will continue to be called struct buf) will handle the vm side of things, the other (struct ioreq) will handle the I/O side of things. My concern is that this will be confusing for driver writers and people porting drivers from other flavours of UNIX. The I/O request has been called struct buf at least since the Third Edition, and it doesn't seem to make much sense to change it now. I'd propose that we call them struct vmbuf and struct buf instead. phk says this isn't a good idea, because he wants to avoid more changes than necessary. I say this is a good idea, because I want to avoid more changes than necessary. Kirk McKusick would prefer to change the names of both structs, but if one were left, it should be the I/O request. Comments? BTW, phk, I have reports of double faults out of Vinum that go away when these BUF_STRATEGY calls are backed out. I haven't had time to look at them yet, but maybe you'd be interested. Greg -- See complete headers for address, home page and phone numbers finger grog@lemis.com for PGP public key 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?19990820084451.A14964>