Linus Torvalds writes:
>
> 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.
;-) He's not the only one to complain about the tar kludge.
Actually, at one point I had plans for doing this in devfsd (which
would ensure that changes were "written" (queued) immediately).
> 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.
OK, I've dragged Ted into the Cc list, so he can comment.
I'm too tired to argue this point (hopefully Ted will do it:-).
However, I will point out that since we already have the mechanisms in
the kernel for saving permissions (duh), it's fairly trivial to make
use of them.
> > 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.
But that means I can't abolish those butt-ugly device numbers from my
kernel.
> 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.
That's fine. All I'm saying is that to get both ways, I can't rip out
gobs of code from devfs and go all the way with your scheme.
Regards,
Richard....
Permanent: rgooch@atnf.csiro.au
Current: rgooch@ras.ucalgary.ca
-
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