Date: Sun, 11 Jan 2009 21:14:53 -0800 From: perryh@pluto.rain.com To: rick-freebsd2008@kiwi-computer.com Cc: freebsd-hackers@freebsd.org Subject: Re: /dev/dsp* & /dev/audio* devices not present Message-ID: <496ad1cd.5X8ZKwS/WWhYNQ61%perryh@pluto.rain.com> In-Reply-To: <20090111160138.GA2386@keira.kiwi-computer.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>
next in thread | previous in thread | raw e-mail | index | archive | help
"Rick C. Petty" <rick-freebsd2008@kiwi-computer.com> wrote: > On Sat, Jan 10, 2009 at 04:20:58AM -0800, perryh@pluto.rain.com wrote: > > "Rick C. Petty" <rick-freebsd2008@kiwi-computer.com> wrote: > > > > > > 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 > > 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. > > > 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? > > 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. > > Since you aren't supposed to open (say) /dev/tun85, but only > > /dev/tun0, correspondence between readdir and open would not > > demand > > What? Why aren't you supposed to open tun85? I use this behavior > all the time and have for years. It helps keep track of things. > Otherwise I would have to keep my natd configuration, firewall > rules, and openvpn configuration all in sync. Please provide a > reference describing you're not "supposed to" open any arbitrary > tunnelling device. 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. BTW I was slightly off -- it is /dev/tun rather than /dev/tun0 that's supposed to be opened -- but if anything this strengthens my point (see below). > > 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. > > I don't buy that argument at all. If anything it should show > "/dev/tun", Agreed it should be /dev/tun -- see above. > 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. > > > 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, > > 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. You're welcome to research the matter. 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? > > for open(2) to succeed when applied to a name which, according > > to readdir(2), does not exist; > > What? This can happen already-- there is no atomicity between > a readdir and an open. 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. > 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. I hardly think it should be considered a good precedent. > 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. The aspect of devfs that prevents the existence of orphan nodes in /dev is an excellent improvement which strengthens that precedent -- now I can find out from /dev not merely that the system supports a particular device in principle but also whether it 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? > > and it is suboptimal to have "stealth" drivers whose > > availability for use cannot be discovered by examining /dev. > > 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 -- 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. > 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? 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. 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?496ad1cd.5X8ZKwS/WWhYNQ61%perryh>