Date: Wed, 26 Jul 2000 14:44:54 -0700 From: Jack Rusher <jar@integratus.com> To: mjacob@feral.com Cc: freebsd-arch@FreeBSD.ORG Subject: Re: How much do we need the all-singing, all-dancing devfs? Message-ID: <397F5BD6.5104F1E4@integratus.com> References: <Pine.BSF.4.05.10007251523570.16927-100000@semuta.feral.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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. -- Jack Rusher, Senior Engineer | mailto:jar@integratus.com Integratus, Inc. | http://www.integratus.com 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?397F5BD6.5104F1E4>