Date: Mon, 12 Jan 2009 02:02:27 -0600 From: "Rick C. Petty" <rick-freebsd2008@kiwi-computer.com> To: perryh@pluto.rain.com Cc: freebsd-hackers@freebsd.org Subject: Re: /dev/dsp* & /dev/audio* devices not present Message-ID: <20090112080227.GA8590@keira.kiwi-computer.com> In-Reply-To: <496ad1cd.5X8ZKwS/WWhYNQ61%perryh@pluto.rain.com> References: <20090107181032.GA2808@rebelion.Sisis.de> <1231398405.2842.1.camel@daemon2.partygaming.local> <20090108080708.GE1462@roadrunner.spoerlein.net> <4966e5b7.sTBBp%2BJY%2BDDMKG47%perryh@pluto.rain.com> <20090109204014.GA83381@keira.kiwi-computer.com> <496892aa.n9QVqyhWypsSmeIU%perryh@pluto.rain.com> <20090111160138.GA2386@keira.kiwi-computer.com> <496ad1cd.5X8ZKwS/WWhYNQ61%perryh@pluto.rain.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Jan 11, 2009 at 09:14:53PM -0800, perryh@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 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20090112080227.GA8590>