Linus Torvalds <torvalds@transmeta.com> said:
> On Thu, 13 Apr 2000, Richard Gooch wrote:
> > No, you're missing my point. Look back and you'll see I said
> > "underlying disc-based FS". In other words, tunnel through to the FS
> > that devfs is mounted on (i.e. /) and read/write permissions
> > there. That's to get persistence across reboots. I'm not talking about
> > persistence while booted.
> See, this is where I think you should think "tar" or "cpio". Don't make it
> fancier than it has to be.
Would you advocate using a filesystem for your home where you have to drag
permissions and ownership for files out of a backup each time you log in?
> After all, you can already read all the permissions from user space. Why
> need any kernel help to maintain them?
Because they have to stick around from the moment they are changed, not
just at the convenience of shutting down normally and running a backup at
that point in time.
> > This is one of the things Ted complained about early on, that devfs
> > didn't do this right from the start, requiring the "tar kludge" to
> > save and restore permissions.
> Ted is on some experimental drugs, and he's much better now, I'm told.
>
> Seriously, "tar kludge" is the wrong way to think about this. Having some
> extra kernel functionality to do something that we already have an
> =existing= program to do, with no additional advantage, now _that_ is a
> kludge.
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.
-- Dr. Horst H. von Brand mailto:vonbrand@inf.utfsm.cl Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513- 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:21 EST