Date: Sat, 10 Jan 2009 04:20:58 -0800 From: perryh@pluto.rain.com To: uspoerlein@gmail.com, rick-freebsd2008@kiwi-computer.com Cc: freebsd-hackers@freebsd.org Subject: Re: /dev/dsp* & /dev/audio* devices not present Message-ID: <496892aa.n9QVqyhWypsSmeIU%perryh@pluto.rain.com> In-Reply-To: <20090109204014.GA83381@keira.kiwi-computer.com> References: <20090107181032.GA2808@rebelion.Sisis.de> <1231398405.2842.1.camel@daemon2.partygaming.local> <20090108080708.GE1462@roadrunner.spoerlein.net> <4966e5b7.sTBBp%2BJY%2BDDMKG47%perryh@pluto.rain.com> <20090109204014.GA83381@keira.kiwi-computer.com>
next in thread | previous in thread | raw e-mail | index | archive | help
"Rick C. Petty" <rick-freebsd2008@kiwi-computer.com> wrote: > On Thu, Jan 08, 2009 at 09:50:47PM -0800, perryh@pluto.rain.com wrote: > > > In principle, everything that would be successfully created if > > open(2)'ed. It doesn't necessarily need to actually create them, > > but the results from readdir(2) should be as if they had been > > created. The whole point of things like ls(1) and readdir(2) is > > to find out what-all is available to be opened, without having to > > already know the answer. > > That's not how devfs works. It's actually a feature > that devfs doesn't list everything ever possible http://storage9.myopera.com/freejerk/files/bug-feature.jpg > (things looked terrible back in the old MAKEDEV days with > all those polluted names). Yes, MAKEDEV can create the opposite problem, wherein /dev contains nodes for devices whose drivers and/or hardware aren't present. Such orphan nodes aren't a whole lot better than missing nodes. > I'd rather be able to list to see things that are in use, although > at first glance I didn't like devfs hidden nodes. Otherwise you'd > be stuck printing tunXXX through infinity instead of this: > > % ls /dev/tun* > /dev/tun0 /dev/tun115 /dev/tun194 In any other part of the directory tree we expect ls to provide a list of names that are available to be opened (subject to permissions). Why should /dev be any different? Since you aren't supposed to open (say) /dev/tun85, but only /dev/tun0, correspondence between readdir and open would not demand that readdir return the (large, if not infinite) list of potential instances. It would however seem reasonable for that ls command to show /dev/tun0 if its driver is loaded, even if the device has not been instantiated because the node has never been opened. > This is not a bug, it is designed behavior. It was intentionally > written to dynamically create device nodes when needed. That the code faithfully adheres to the design does not guarantee that the design is flawless. IMO it violates POLA, if not POSIX, for open(2) to succeed when applied to a name which, according to readdir(2), does not exist; and it is suboptimal to have "stealth" drivers whose availability for use cannot be discovered by examining /dev.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?496892aa.n9QVqyhWypsSmeIU%perryh>