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

[der Mouse <mouse%Rodents-Montreal.ORG@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.

I don't see why not.  It breaks a few things, but only a few.

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

dev_t was, and is, a kludge, to deal with devices in the relatively
primitive filesystem Unix used back in its early days (well, I think
they might have been ints then, rather than dev_t, but the difference
between the two is trivial).  It's good enough for most purposes and
its problems have been relatively minor so far, so it's survived, but
there's nothing sacred about it.

Everything starts somewhere.  I would never go near Uebayashi-san's
devfs in any of the incarnations described so far on a production
system.  But I think it's high time someone started thinking about, and
experimenting with, alternatives to traditional device nodes and device
numbers, and I'm glad to see this happening.  If and when this gets to
the point of being contemplated for production use, that is the time to
worry about compatability with historical practices and decide whether
historical compatability must be maintained or an incompatability is
acceptable.  There have been flag days before and there will be again;
doing away with dev_t might - or might not - be one of them.

> Stuff like "find -x" needs to keep on working (that uses dev_t),

find -x might need to keep working (or might not; if filesystem
mounting changes sufficiently it may no longer make sense, not that
changes filesystem mounting seem to me to be part of this).  There is
nothing that says it has to continue working with exactly the same
dev_t-based implementation it traditionally has - and even if it does,
that needs dev_ts only for st_dev fields, not for special device nodes
in the filesystem; the use of the same thing for both is a historical
accident that I see no particular need to preserve.  find -x cares
about dev_t only in the sense that it equates "a.st_dev==b.st_dev" with
"a and b are on the same filesystem"; something like indices into an
array of mount points, or event-of-mounting serial numbers, would work
equally well for those purposes.

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

Not given devfs.  With a devfs, backing up device nodes makes about as
much sense as backing up AF_LOCAL sockets does now.

> 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, [...] [it] just might be the interface that is actually
> best for the usage it gets [...]

A valid point.  But it could also be that nobody has thought radically
enough to come up with the interface that _is_ better - somewhat a la
"your idea is crazy, but not crazy enough to be true".

Most research experiments go nowhere.  But they must be done, or the
few that do turn out to be important would never happen; almost by
definition, nobody knows ahead of time which research experiments will
turn out to be useless and which ones will turn out to be advancements
in the state of the art.

With that in mind, I'd say that the more radical Uebayashi-san's devfs
is, the less like past (failed) attempts at devfses it is, the more
likely it is to turn out to be a better way.  Eliminating (this use of)
dev_t is an example.

/~\ The ASCII                             Mouse
\ / Ribbon Campaign
 X  Against HTML                mouse%rodents-montreal.org@localhost
/ \ Email!           7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B