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.
After all, you can already read all the permissions from user space. Why
need any kernel help to maintain them?
> 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.
> And you didn't answer how I can have different permissions, or simply
> not expose device entries, on a selective basis, *and have different
> selections each time you mount devfs*. This is important for chroot()
> gaols.
I don't agree about that being all that important.
If you want to have a limited chroot environment, what's wrong with
cp -a /dev/xxx /dev/yyy /dev/zzz ... /chroot/dev
and be done with it? If you already know what devices you want to have,
there's not all that much of a point in having devfs at all. Remember,
chroot is for special events and purposes, it's not some general-purpose
thing that has to offer everything.
Also note that what Al Viro's patches do does not _require_ that you have
an exact copy. If you want the exact copy, then you just re-mount the
earlier mount somewhere else. That's often what you _do_ want, because the
thing you're mounting may need to be that way (think /proc, or think
shmfs).
But there's nothing fundamentally wrong in mounting separate copies -
they'll just be completely independent, with separate dentry trees and
separate superblocks. They'll have the same code and logic, but not
necessarily the same entries.
Think of it like the clone() issue - either you get a identical clone()
(ie a thread that has the exact same VM) or you get something that just
looks the same but really doesn't share anything at all (ie a fork()).
Both are useful.
Linus
-
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:20 EST