On Sat, Jan 10, 2009 at 04:20:58AM -0800, per...@pluto.rain.com wrote: > "Rick C. Petty" <rick-freebsd2...@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 _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
