From owner-freebsd-hackers@FreeBSD.ORG Sun Jan 11 16:01:40 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8A00B1065670 for ; Sun, 11 Jan 2009 16:01:40 +0000 (UTC) (envelope-from rick@kiwi-computer.com) Received: from kiwi-computer.com (keira.kiwi-computer.com [63.224.10.3]) by mx1.freebsd.org (Postfix) with SMTP id 3BE078FC0C for ; Sun, 11 Jan 2009 16:01:39 +0000 (UTC) (envelope-from rick@kiwi-computer.com) Received: (qmail 2888 invoked by uid 2001); 11 Jan 2009 16:01:38 -0000 Date: Sun, 11 Jan 2009 10:01:38 -0600 From: "Rick C. Petty" To: perryh@pluto.rain.com Message-ID: <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+JY+DDMKG47%perryh@pluto.rain.com> <20090109204014.GA83381@keira.kiwi-computer.com> <496892aa.n9QVqyhWypsSmeIU%perryh@pluto.rain.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <496892aa.n9QVqyhWypsSmeIU%perryh@pluto.rain.com> User-Agent: Mutt/1.4.2.3i Cc: freebsd-hackers@freebsd.org Subject: Re: /dev/dsp* & /dev/audio* devices not present X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rick-freebsd2008@kiwi-computer.com List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jan 2009 16:01:40 -0000 On Sat, Jan 10, 2009 at 04:20:58AM -0800, perryh@pluto.rain.com wrote: > "Rick C. Petty" 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'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. > 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. > 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", 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? > > 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. > 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. And what about msdosfs and case-insensitivity? You can certainly open files that weren't a part of your readdir. 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. > and it is suboptimal to have "stealth" > drivers whose availability for use cannot be discovered by examining > /dev. Why is it suboptimal? 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. -- Rick C. Petty