From owner-freebsd-arch Thu Jul 27 0:32:24 2000 Delivered-To: freebsd-arch@freebsd.org Received: from ywing.creative.net.au (ywing.creative.net.au [203.56.168.34]) by hub.freebsd.org (Postfix) with ESMTP id BF36D37B959 for ; Thu, 27 Jul 2000 00:32:20 -0700 (PDT) (envelope-from adrian@ywing.creative.net.au) Received: (from adrian@localhost) by ywing.creative.net.au (8.9.3/8.9.3) id JAA73182 for freebsd-arch@freebsd.org; Thu, 27 Jul 2000 09:40:15 +0200 (CEST) (envelope-from adrian) Date: Thu, 27 Jul 2000 09:40:15 +0200 From: Adrian Chadd 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> References: <397F5BD6.5104F1E4@integratus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <397F5BD6.5104F1E4@integratus.com>; from jar@integratus.com on Wed, Jul 26, 2000 at 02:44:54PM -0700 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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_ 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