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

[perryh at pluto.rain.com]

Ulrich Spoerlein <gmail.com!uspoerlein at agora.rdrop.com> wrote:

> I cannot really comment on the devfs(4) design issues,
> and quite frankly it hasn't bothered my thus far.

It evidently inconvenienced the OP.

> Just another little quirk you get to remember.

If we followed that line of reasoning to its logical
conclusion we would eliminate POLA entirely.

> > 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.
>
> You forgot directories with --x permissions. You can open many
> files inside them, but readdir(2) will get you nowhere. So this
> is a poor standard by which to judge devfs(4) device cloning.

There are at least two problems with that analysis:

* /dev does not ordinarily have --x permissions.  Even if I amended
  the principle to allow for that case, it would not affect its
  application to this case.

* readdir works for root, even in directories with --x permissions.
  For example:

  $ mkdir test
  $ touch test/file
  $ ls -la test
  total 4
  drwxr-xr-x  2 perryh  perryh  512 Jan 10 15:39 .
  drwxr-xr-x  3 perryh  perryh  512 Jan 10 15:39 ..
  -rw-r--r--  1 perryh  perryh    0 Jan 10 15:39 file
  $ chmod 111 test
  $ ls -ld test
  d--x--x--x  2 perryh  perryh  512 Jan 10 15:39 test
  $ ls -la test
  total 0
  ls: test: Permission denied

  # ls -la test
  total 4
  d--x--x--x  2 perryh  perryh  512 Jan 10 15:39 .
  drwxr-xr-x  3 perryh  perryh  512 Jan 10 15:39 ..
  -rw-r--r--  1 perryh  perryh    0 Jan 10 15:39 file