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

On Sun, Jan 11, 2009 at 09:14:53PM -0800, perryh@xxxxxxxxxxxxxx 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
previous statements.

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
exist.

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
precedence.

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
system

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
/dev/sndstat?

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
opened.

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
device driver.

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
now.

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
_______________________________________________
freebsd-hackers@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@xxxxxxxxxxx"

Relevant Pages

  • Re: /dev/dsp* & /dev/audio* devices not present
    ... That's not how devfs works. ... But this isn't a bug disguised as a feature. ... correspondence between readdir and open would not ... interface permits opens on the special control device /dev/tun. ...
    (freebsd-hackers)
  • Re: /dev/dsp* & /dev/audio* devices not present
    ... That's not how devfs works. ... nodes for devices whose drivers and/or hardware aren't present. ... correspondence between readdir and open would not demand ... That the code faithfully adheres to the design does not guarantee ...
    (freebsd-hackers)
  • Re: Control Panel Problems
    ... You might want to check the Sonic website for updates for the software. ... compatible drivers. ... If I go to start/control panel it opens up. ... >>>>> If your system is clear of viruses, open Control Panel, open System, ...
    (microsoft.public.windowsxp.accessibility)
  • Re: Sio & Puc memory mapped
    ... They are essentially a good set of defaults for interactive shells, ... It just opens _PATH_CONSOLE and does ... Thus console drivers must do the same termios initialization ...
    (freebsd-current)