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

[perryh at pluto.rain.com]

"Rick C. Petty" <rick-freebsd2008 at kiwi-computer.com> wrote:

> On Thu, Jan 08, 2009 at 09:50:47PM -0800, perryh at 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.