Date: Mon, 10 Apr 2000 20:56:50 +0200 From: Poul-Henning Kamp <phk@critter.freebsd.dk> To: Julian Elischer <julian@elischer.org> Cc: arch@freebsd.org Subject: Re: BUF/BIO roadmap. Message-ID: <25105.955393010@critter.freebsd.dk> In-Reply-To: Your message of "Mon, 10 Apr 2000 08:24:53 PDT." <38F1F245.2781E494@elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <38F1F245.2781E494@elischer.org>, Julian Elischer writes: >>From memory, I managed to do this without having a pbklno and a >lblkno.(I noticed that you still have both in the document) in the >bio struct (my ioreq) so I wonder whether it is really needed. >(I may have got the names wrong as the document is not in front of me) With the stackable BIO pblkno either go away or get modified to be more general. Performance-wise pblkno *in some form* makes sense, there is no point in allocating a new struct bio for the basic slicer like MBR or BSD since only the offset is changed. One way to do this is to have a separate field in buf/bio and copy it in DEV_STRATEGY. This would make the bio_ field owned by the BIO subsystem and as such modifiable. iodone_chain goes away and bio_done becomes nestable. >You make no mention as to how one maps >an arbitrarily stacked set of partitions into minor numbers. >(i.e. what is the minor number of a partition called da2s1de Arbitrarily stacked nodes may require either a DEVFS or a devd (or geomd ?) to handle that issue. Backwards compatible stacking (ie: MBR then BSD) will use legacy minors to perserve POLA. >Unless we get BSDI style interrupt threads, the idea of propogating >up 'probe' operations cannot be done safely It sure can, but you need a kernel or user process to do the grunt work. A user process may be desirable for other reasons. >The Other problem I faced was the possibility that >when a low level device was open, the user might re-write the >structures that defined some upper layer devices. My solution for >that was that on the close() of the lower level device, all >the upper level devices were asked to verify that they were >still valid. It is certainly a sticky issue no matter how you tackle it, and I am more than a little bit tempted to apply root-inteligence rather than code complexity to this problem. A re-probe on close is probably the only sane, simplest and most POLA preserving action available. >In the downward propogation of open() and close() calls, we need to >propogate independently open-for-read() and open-for-read+write() >If one partition is already open for read and the another is openned >for read/write, then the 'downstream' device needs to be upgraded for >read/write. Obviously. >Justin Gibbs suggested that this call should also allow the driver >to know WHO is making hte call, Yeah, but unfortunately we loose that information long before we get to that point, from memory I belive it was VOP_OPEN which discards all but the credentials. The dup(2) problem in other words. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD coreteam member | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?25105.955393010>