Date: Wed, 26 Jul 2000 02:35:06 +0200 From: Adrian Chadd <adrian@freebsd.org> To: Matthew Jacob <mjacob@feral.com> Cc: freebsd-arch@freebsd.org Subject: Re: How much do we need the all-singing, all-dancing devfs? Message-ID: <20000726023506.A68912@ywing.creative.net.au> In-Reply-To: <Pine.BSF.4.05.10007251523570.16927-100000@semuta.feral.com>; from mjacob@feral.com on Tue, Jul 25, 2000 at 03:37:33PM -0700 References: <397E0DF2.FDC595C5@integratus.com> <Pine.BSF.4.05.10007251523570.16927-100000@semuta.feral.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Jul 25, 2000, Matthew Jacob wrote: > > Matthew Jacob wrote: > > > > > > ad hoc, even as it is now- 'camcontrol devlist' and parsing dmesg output. > > > > This is what I was afraid of. It strikes me that this sort of sucks, > > Yes. > > > and that there really should be a better way. This is the sort of thing > > that a devfs is meant to make go away, isn't it? > > 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. > > Why is this so? Well, it's so because it makes the problem set more > manageable. The list of all possible devices that can be instantiated is > related to which drivers you have loaded. But the loading of drivers in order > to know whether to really instantiate a node in /dev is related to information > held possibly by *another* driver (one which may not be a 'device', and, > unlike the assumptions of the Solaris model of nexus drivers, may not have an > obligate parent relationship). Right, so if I understand all this discussion right, you want to be able to take a name which can represent a changing target, and present that in devfs, correct? Being totally naieve(sp?) here, but why can't you just tie in the devfs namei() into newbus somehow? Is there any reason why you can't have some form of device hierarchy inside /dev besides the (mostly) flat namespace that already exists? Think things like vinum. I like the /dev/vinum/volumename abstraction. If you are doing Fibrechannel stuff (which I'll admit I know *nothing* about) and you want to be able to reference a target which could possibly change between reboots, why not just have the CAM subsystem register /dev/scsi/ with devfs, and handle things itself in there? Or, you could abstract it further, and have /dev/disklabel/<disklabelname> and let the disklabel code handle mapping a name to a device? I think this is what phk mentioned earlier about polling a list of drivers, I'd just like to bring the concept out into the open more for discussion. 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?20000726023506.A68912>