Date: Sun, 11 Jan 2009 10:01:38 -0600 From: "Rick C. Petty" <rick-freebsd2008@kiwi-computer.com> To: perryh@pluto.rain.com Cc: freebsd-hackers@freebsd.org Subject: Re: /dev/dsp* & /dev/audio* devices not present Message-ID: <20090111160138.GA2386@keira.kiwi-computer.com> In-Reply-To: <496892aa.n9QVqyhWypsSmeIU%perryh@pluto.rain.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> <496892aa.n9QVqyhWypsSmeIU%perryh@pluto.rain.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Jan 10, 2009 at 04:20:58AM -0800, perryh@pluto.rain.com wrote: > "Rick C. Petty" <rick-freebsd2008@kiwi-computer.com> wrote: > > > > 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 Funny. But this isn't a bug disguised as a feature. It's a feature that you believe is a bug. > > 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? Because it's a special filesystem. > Since you aren't supposed to open (say) /dev/tun85, but only > /dev/tun0, correspondence between readdir and open would not demand What? Why aren't you supposed to open tun85? I use this behavior all the time and have for years. It helps keep track of things. Otherwise I would have to keep my natd configuration, firewall rules, and openvpn configuration all in sync. Please provide a reference describing you're not "supposed to" open any arbitrary tunnelling device. > 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. I don't buy that argument at all. If anything it should show "/dev/tun", but why create device nodes when they aren't necessary, as you have to clone the nodes (or create new ones) when an actual open(2) occurs? > > 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, Please provide the reference where it violates POSIX. > for open(2) to succeed when applied to a name which, according to > readdir(2), does not exist; What? This can happen already-- there is no atomicity between a readdir and an open. And what about msdosfs and case-insensitivity? You can certainly open files that weren't a part of your readdir. Also no one in their right mind would be coding a readdir/open solution against a filesystem known to be completely dynamic and especially against devfs. You would want to tie in directly to devctl, sysctl, or syscall. > and it is suboptimal to have "stealth" > drivers whose availability for use cannot be discovered by examining > /dev. Why is it suboptimal? I think you have that backwards-- it's more optimal not to have to create superfluous device nodes when they are not needed, at least from the kernel efficiency perspective. -- Rick C. Petty
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20090111160138.GA2386>