Re: (Semi-random) thoughts on device tree structure and devfs

[Eric Haszlakiewicz <erh%nimenees.com@localhost>]

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:
> You're barking up the wrong tree.  What's annoying is not that the
> numbering changes.  It is that the numbering is relevant to the use of
> the device.  I expect dk(4) devices to be given names (be it real names
> or GUIDs), and I expect to be able to use that whenever I currently have
> to use a string of the form "dkN".

fwiw, this matches my expectation too.

> > - 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.

> > Common code is concentrated in single place.  Each driver implements only 
> > its
> > hardware accessors.  No scattered ioctl handlings.
> You forgot world peace.
:)

> > 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?

eric