Date: Sat, 10 Jan 2009 19:51:35 +0100 From: Ulrich Spoerlein <uspoerlein@gmail.com> To: perryh@pluto.rain.com Cc: rick-freebsd2008@kiwi-computer.com, freebsd-hackers@freebsd.org Subject: Re: /dev/dsp* & /dev/audio* devices not present Message-ID: <20090110185135.GB83079@roadrunner.spoerlein.net> In-Reply-To: <496892aa.n9QVqyhWypsSmeIU%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>
next in thread | previous in thread | raw e-mail | index | archive | help
I cannot really comment on the devfs(4) design issues, and quite frankly it hasn't bothered my thus far. Just another little quirk you get to remember. On Sat, 10.01.2009 at 04:20:58 -0800, perryh@pluto.rain.com wrote: > That the code faithfully adheres to the design does not guarantee > that the design is flawless. IMO it violates POLA, if not POSIX, > for open(2) to succeed when applied to a name which, according to > readdir(2), does not exist; and it is suboptimal to have "stealth" > drivers whose availability for use cannot be discovered by examining > /dev. You forgot directories with --x permissions. You can open many files inside them, but readdir(2) will get you nowhere. So this is a poor standard by which to judge devfs(4) device cloning. Cheers, Ulrich Spoerlein -- It is better to remain silent and be thought a fool, than to speak, and remove all doubt.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20090110185135.GB83079>