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

[Richard Gooch]

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: [e-mail]
Current:   [e-mail]