Date: Thu, 27 Jul 2000 09:40:15 +0200 From: Adrian Chadd <adrian@freebsd.org> To: freebsd-arch@freebsd.org Subject: Re: How much do we need the all-singing, all-dancing devfs? Message-ID: <20000727094015.B71137@ywing.creative.net.au> In-Reply-To: <397F5BD6.5104F1E4@integratus.com>; from jar@integratus.com on Wed, Jul 26, 2000 at 02:44:54PM -0700 References: <Pine.BSF.4.05.10007251523570.16927-100000@semuta.feral.com> <397F5BD6.5104F1E4@integratus.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Jul 26, 2000, Jack Rusher wrote: > Matthew Jacob wrote: > > > > No- not really. A devfs should allow one to dynamically bind a meaningful > > name to a device- so you don't get stuck with inodes on disk that don't > > point to what you think the name in /dev (which is what you use in > > /etc/fstab or other apps) points to. > > > > Complete discovery of all potential devices that can then be instantiated in > > /dev is a related but separate problem. > > Hmm. I understand why you would want to divide and conquer on this > problem, but it seems to me that you would want to do you top level > design in a way that allows these things to coexist and be developed one > at a time. > > From a "driver figures out what to load" perspective, I find it very > useful to have drives hanging from a controller in a tree structure so > that I can write tools that are able to intelligently figure out how to > balance I/O over controllers. What is the win from avoiding a tree > based device layout? > > Adrian Chadd's notion of a node under dev (say, /dev/fc0 for the first > fibre channel controller) that returns listings of underlying devices > (by sending queries to the drivers) has some potential merit. There is > the chance, however, that I am thinking about things from too much of a > Plan9 perspective. I just like the idea of using file system semantics > for databases; especially with links to provide multiple names for a > resource. Kind of. From my understanding of the way devices/VFS holds together, the underlying devsw can't change while the machine is running, so your (SCSI/IDE/Fibrechannel) device drivers and whatever disklabel layer you use would have to keep the devsw mapping static. Your disklabel layer would then register say, /dev/dsk/, and then it can control what names are returned. But it doesn't even have to do this if you wanted to keep the device labels in /dev and call them, say, /dev/disk-$label, you should be able to do that with make_dev(). Matt - if I understand your initial idea right, all you wanted was a way to map a fibrechannel disk label to a name in a devfs, so that when the underlying device shifted 'address', you would still be able to reference it without difficulty? Was there anything else ? Adrian -- Adrian Chadd Now 17-year-olds can't play a _video game_ <adrian@FreeBSD.org> because its called violent - and real violence is still called dinner. -- jamie@mccarthy.org 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?20000727094015.B71137>