> > You know, there were flamewars about this exact point around devfs for
> > _years_... and no magic solution came forth, not even an idea for a
> > workable solution.
> My, you have a selective memory. I've proposed more than one workable
> solution to this:
>
> - tar/untar (it may not appeal to you, and it doesn't appeal to me
> that much either, but it will do the job)
It is horrible, and breaks in any case where the machine isn't shut down
cleanly. No dice.
> - set permissions in /etc/devfsd.conf, edit to change
Doesn't work at all with chmod/chown. No dice.
> - configure devfsd to automatically save/restore (possible *right
> now*, although requires configuring, I could provide a canned
> solution to make it easier)
How would this work over crashes?
> - tunnel through to the underlying disc-based FS we're mounted over.
Then get rid of the crud over the disk-based filesystem, which you wanted
to get rid of in the first place.
> You personally might not like some or all of them, but they do/will
> *work*. They will get the job done.
Work sort of, perhaps. But they don't answer to the fundamental question
about persistence in any way that I would call clean, much less elegant.
Sure, the disk-based /dev can become a mess, but what I see here is
exchanging a rather well-understood (if ugly) mess with a whole new one,
which furthermore is _different_ from the way the rest of the filesystem
works, and how this (rarely visited, but critical) area works in Linux and
in other Unices. And that I consider dangerous.
-- Horst von Brand vonbrand@sleipnir.valparaiso.cl Casilla 9G, Viņa del Mar, Chile +56 32 672616- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/