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

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Wed, 10 Mar 2010 21:21:21 +0900
    From:        Masao Uebayashi <uebayasi%gmail.com@localhost>
    Message-ID:  
<70f62c5e1003100421s5c54035bkdee5917165b0104d%mail.gmail.com@localhost>

  | dev_t will be no longer used.

I'm not sure if something that blatant (unqualified) is actually what
you meant to say, but if it was, you cannot do that.

dev_t (however poorly designed you might think it to be) is a part of
the kernel/application API that has been there forever, and is not
going away any time soon.

Stuff like "find -x" needs to keep on working (that uses dev_t), and for
that matter, doing a backup of a device tree using cpio, then restoring
it later (however insane it really is to use cpio for this kind of
purpose) needs to keep on working.

How the kernel actually associates between drivers and code that needs
to access the drivers is a whole different issue, and if your plan is
just to replace usages like
        (*bdevsw[major(dev)].d_strategy)(...);
with something different, then that might be OK, but both the dev_t
and the minor() and major() macros to interpret it simply have to
remain.

Part of what I am seeing when reading this discussion is that it doesn't
appear as if any two participants have any real idea what the others are
talking about - everyone is focusing only upon their pet need or desire,
and no-one is really looking at the big picture.

I have no real opinion on how all this should be done, just two hints
for how a solution to whatever problem actually exists should be
investigated.   First don't start with, and certainly don't concentrate
on, disks - they're way too easy (complicated sure, but it isn't hard
to come up with solutions that seem to work for disks).  Probably even
network interfaces (not that we really treat them as devices anyway),
what you need to make work properly are devices like tape units, cd
readers & writers (with nothing loaded in them), serial line interfaces
(com ports, or tty devices), line printer interfaces (parallel ports),
GPIO pins, cameras, audio devices, ...

eg: if I have a system with two separate audio devices, one wired to
speakers in one room, the other wired to speakers in a different room,
how do I know which name to use to get the sound in the right place?

All of this usually turns out to be really hard ...  and with that in
mind, my second hint - when you see an interface that has been around
for a very long time, and is still being used, essentially everywhere,
and where despite numerous attempts to "fix" it, none of the proposals
(or more importantly, implementations) has really caught on as "that
one is a much better way", then when investigated, it often turns out
that however crufty the existing interface is, if just might be the
interface that is actually best for the usage it gets (and the longer
it has been around, and the more expectations there are on how it works,
the less likely it is that anything different is actually going to be
better.)

kre