/dev/dsp* & /dev/audio* devices not present
Rick C. Petty
rick-freebsd2008 at kiwi-computer.com
Mon Jan 12 00:02:28 PST 2009
On Sun, Jan 11, 2009 at 09:14:53PM -0800, perryh at pluto.rain.com wrote:
> > Funny. But this isn't a bug disguised as a feature.
> > It's a feature that you believe is a bug.
> I would call it a bug that you believe is a feature.
Not just me, but freebsd developers including those who wrote devfs.
> > > 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.
> I think that constitutes an admission that it violates POLA,
> and it's not much of a justification IMO.
Only you and a small group of people seem to be astonished by this,
something that's been in FreeBSD since 4.0. Glad you're voicing your
opinion now, before it's too late.
> The manpage for tun(4) says:
> tun does for network interfaces what the pty(4) driver does for
> terminals ... The network interfaces are named ``tun0'', ``tun1'',
> etc., one for each control device that has been opened ... The tun
> interface permits opens on the special control device /dev/tun.
> When this device is opened, tun will return a handle for the
> **lowest** unused tun device ...
> (emphasis added). The whole point of cloning devices is to avoid
> the need for the application to loop through a sequence of possible
> names to find one that is not in use; it simply opens the generic
> name and gets a (pseudo) device.
Yes, when using /dev/tun, you get the lowest. That's expected behavior.
But it doesn't say not to use your own numbering. I'll stand by my
> > 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?
> As I stated earlier in this thread:
> * It doesn't necessarily need to actually create them, but the
> * results from readdir(2) should be as if they had been created.
I think you may find this is not as trivial as you make it sound.
> > Please provide the reference where it violates POSIX.
> I am not familiar with POSIX in detail, which is why I only suggest
> that it *may* violate POSIX.
That much is obvious.
> You're welcome to research the matter.
No thanks, I've read it back to front. But you seem to imply that you're
the expert, so I was hoping for you to point out how I've misread it.
> I would *expect* that research to find that there is supposed to be
> a correspondence between what readdir reports as the contents of a
> directory, and the results of attempting to open a filename in the
> directory whose contents were read; if not, what would be the point
> of having readdir in the first place?
Good point. We should probably rewrite syscalls to use vnode references
instead of names. That would solve all ambiguity problems as well.
> Of course not, but we are not dealing here with a case in which
> process A reads the directory, then process B creates a file in
> it, and thus that file becomes visible to process A. Instead we
> have a magical side-effect, wherein process A opens a file which
> (per readdir) does not exist, and thereby calls into existence a
> new file, while the name that process A opened *still* does not
There is nothing magical about it, nor did this just happen overnight.
Perhaps it's not well-documented but it is well-known.
> > And what about msdosfs and case-insensitivity? You can
> > certainly open files that weren't a part of your readdir.
> The semantics of msdosfs are driven by the need to maintain
> compatibility with a certain other operating system -- the one
> which defined that filesystem representation in the first place.
Just like devfs, which defined the filesystem representation that there are
invisible nodes and pseudo-nodes.
> I hardly think it should be considered a good precedent.
Obviously kernel developers disagreed with you.
> > 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.
> Programmatically, yes. But long-standing historical precedent,
> going back at least as far as the AT&T sixth research edition,
> would have an administrator or knowledgeable user believe that the
> contents of /dev are related to the collection of drivers that the
> system supports.
So we should go back to the precedent and make all dev entries static once
again? You can't argue for progress in the same case that you argue for
> actually has that device attached. Why would we want to trash that
> concept by allowing the existence of phantom drivers, which have no
> presence in /dev unless/until they have been opened?
The drivers aren't phantom-- their instances are.
> > Why is it suboptimal?
> As in the case of the OP, it is suboptimal from the standpoint of
> a human who wants to know what devices and drivers exist in the
You mean a human who does not understand enough about devfs to know its
design quirks? This same human who does not care to look in
/var/run/dmesg.boot? This same human who expects FreeBSD to behave as any
other OS when it comes to device drivers and doesn't know to check
That's not what I think about when I hear the word "suboptimal". I think
you're trying to argue that certain devfs semantics are confusing to
beginners. I would call that perhaps "confusing" or perhaps "misleading"
(which is a stretch).
> -- AFAIK the output of ls(1) is intended primarily for human
> consumption. Of course, for ls(1) to do its job, readdir(2) has to
> provide the data.
ls(1) is doing its job. Perhaps your argument for having one non-phantom
device node appear for each driver is useful, but don't discount the
utility and flexibility of phantom nodes in other cases. I agree that
better documentation would also help. So I look forward to your patches
for either of these areas.
> > 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.
> If /dev/tun does not exist, how does an open on it succeed?
Who says it doesn't exist? The open succeeds so it apparently does exist.
In unix, there's never been a guarantee that after you readdir that an open
will succeed, nor that a subsequent readdir will show the file you've
> Either there is special-case code that somehow scans the list of
> installed drivers in addition to examining the contents of /dev, or
> the node actually exists but readdir avoids reporting its existence.
I don't think you understand how devices work (specifically, pseudo
devices). You may wish to look at make_dev(9) and maybe source code for a
> Either way, the kernel is having to do extra work to maintain the
> disagreement between the contents of the directory as reported by
> readdir and the list of names that are known to open.
No, I believe it's less work this way, but I'm no expert here. I did not
design devfs nor did I like it myself initially, but after time I grew to
prefer it and its behavior. This issue about invisible device nodes has
come up numerous times in the past and I believe its proponents and
opponents have argued it to death which is why no one else is speaking up
I encourage you to submit patches. Either you will find it more difficult
your way or you may have a difficult time convincing others of its
necessity. Just disagreeing with me will not change anything.
-- Rick C. Petty
More information about the freebsd-hackers