/dev/dsp* & /dev/audio* devices not present

[Rick C. Petty]

On Sat, Jan 10, 2009 at 04:20:58AM -0800, perryh at pluto.rain.com wrote:
> "Rick C. Petty" <rick-freebsd2008 at 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