On Sun, Mar 07, 2010 at 10:31:52PM -0600, Eric Haszlakiewicz wrote: > On Sun, Mar 07, 2010 at 08:50:03PM +0000, Quentin Garnier wrote: > > On Sun, Mar 07, 2010 at 06:43:49PM +0900, Masao Uebayashi wrote: [...] > > > - Intuitivity > > > Behavior should be simple enough for users to guess without looking into > > > code. > > > > What kind of user do you talk about here? If it's the end user, then > > this is wrong. All that you mention should be irrelevant to them. > > Careful here: does "end user" mean grandma clicking though KDE, or an admin > figuring out why one disk of his raid component disappeared? More precise > definitions and terminology might be helpful. Well, even if the admin gives proper names to all the disks and such, yes, there is one moment when they'll be faced with details of the device tree. But to me it's a brief part of the setup, not really of the use. The click-through user has their administrative tasks proxied by things like hald(8), but I expect said proxy to see as little gory details as a human admin as well. [...] > > > 1) Introducing devfs > ...snip... > > Beside, imagine you move said hard drive from one port to the other (or > > on to another, say, faster controller); the ultimate idea of devfs is > > that the device node for the hard drive doesn't change. > > > > Not that full, explicit device paths aren't something useful to expose > > one way or another to the userland. It's just not what devfs is about, > > so you should revise your vocabulary here. > > I thought this was *one* of the things that devfs was supposed to do. The > two features being: > 1) provide a way to see detailed information about how devices are laid out > and, the one relevant for this discussion > 2) provide stable names for devices that don't change if they happen to be > laid out differently today vs. yesterday. > > with #2 possibly provided by a userland script that parses the structure > provided by #1, plus whatever additional information it needs, and creates > symlinks (or otherwise causes device nodes to appear in the right paths) > #2 == simplicity, #1 == transparency and (low level) control > > Perhaps I'm muddling the base feature requirements with various ideas for > implementations? There's nothing complicated about what devfs is for: having all the relevant device nodes in /dev, and only those. Anything else is an implementation detail. Neither #1 or #2 are part of the immediate goal of devfs. I don't see why #1 should be a part of a devfs implementation, and #2 is certainly something nice to have, but it goes beyond the initial intent of a devfs. -- Quentin Garnier - cube%cubidou.net@localhost - cube%NetBSD.org@localhost "See the look on my face from staying too long in one place [...] every time the morning breaks I know I'm closer to falling" KT Tunstall, Saving My Face, Drastic Fantastic, 2007.
Attachment:
pgpAxPH71bMCx.pgp
Description: PGP signature