Date: Tue, 25 Jul 2000 15:37:33 -0700 (PDT) From: Matthew Jacob <mjacob@feral.com> To: Jack Rusher <jar@integratus.com> Cc: freebsd-arch@FreeBSD.ORG Subject: Re: How much do we need the all-singing, all-dancing devfs? Message-ID: <Pine.BSF.4.05.10007251523570.16927-100000@semuta.feral.com> In-Reply-To: <397E0DF2.FDC595C5@integratus.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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). That is to say, the devfs that I believe is being considered here is not the hierarchical model that Solaris uses. That being the case, it has no reason to try and represent the hierarchical device tree topology (as does the Solaris model). If that is true, then the entities in the FreeBSD devfs are not the exhaustive current list of all possible known devices, and information about *what* to try and instantiate has to come from another mechanism. The suggestions of 'camcontrol' and 'dmesg' are just to illustrate that there's another big problem to solve after devfs. [ I'm sure Poul && Julian && others will correct me smartly if I've misunderstood or misrepresented the current devfs intents/design ] -matt 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?Pine.BSF.4.05.10007251523570.16927-100000>