Re: Suggested dual human/binary interface for proc/devfs

From: Horst von Brand (vonbrand@sleipnir.valparaiso.cl)
Date: Thu Apr 13 2000 - 20:20:09 EST


Richard Gooch <rgooch@ras.ucalgary.ca> said:
> Horst von Brand writes:
> > Bingo! Keep devices in inodes on disk. To do persistence right, you'll have
> > to keep them in inodes on disk anyway... so this whole kludge can go.
> > Solves the different devices visible with different permissions in
> > different chroot(2)s too, without any extra effort.

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



This archive was generated by hypermail 2b29 : Sat Apr 15 2000 - 21:00:23 EST