Date: Thu, 19 Aug 1999 16:37:51 -0700 (PDT) From: Julian Elischer <julian@whistle.com> To: Greg Lehey <grog@lemis.com> Cc: Poul-Henning Kamp <phk@critter.freebsd.dk>, cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: 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: <Pine.BSF.3.95.990819162240.13522J-100000@current1.whistle.com> In-Reply-To: <19990820084451.A14964@freebie.lemis.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 20 Aug 1999, Greg Lehey wrote: > 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. exactly.. this has been discussed by many people over the last couple of years. including me, matt, kirk, phk, DG (from memory), mike, and others. The naming is more accurate than at present.. the ioreq structure is an IO request. it may be passed to a driver such as ccd or vinum, which may decide to generate a bunch of differnt IO requests in it's place. All this has no effect on the VM or VFS side of things and thus the functionallity of the two structures should be split. It's possible that the io request is what goes through the BMAP process and that the struct buf only knows about the vm object (or vnode) and the offset and size in the object. it may not know where that is physically. (It's possible that the physical location might be cached sometimes but that would be just an optimisation. > > 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. I think that I prefer it the way that PHK is suggesting. a structure for buffer management called struct buf and a structure for IO request management called ioreq. The scope mismatches and value overloading going on in the present struct buf are becoming a real limitation. > > 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. I think I already gave my opinion.. changing both is also a fair idea. (that way we know that someone looked at ALL the places the present struct buf is used.. :-) > > 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. I can imagine this. however consider that the aim of what PHK is trying ot do is to make things more consistant and that it is also possible that teh new code is tripping up on an incorrect or inconsitant use of bufs. > > Greg > -- > See complete headers for address, home page and phone numbers > finger grog@lemis.com for PGP public key > > julian 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?Pine.BSF.3.95.990819162240.13522J-100000>