FS_SINGLE queries
Hi, all. I've just been looking at the FS_SINGLE implementation, and have a few comments: - although not documented, you need to do kern_mount() before trying normal mounts of a FS_SINGLE; perhaps kern_mount()/kern_umount() should be called automatically in register_filesystem()/unregister_filesystem()? - I note that procfs and pipefs call unregister_filesystem() before calling kern_umount(). This looks counter-intuitive, even if it's correct (is it?) - when mounting a FS which is FS_SINGLE, /proc/mounts reports the FS type rather than "bind", which also seems wrong. Regards, Richard Permanent: [EMAIL PROTECTED] Current: [EMAIL PROTECTED]
Re: FS_SINGLE queries
On Sat, 10 Jun 2000, Richard Gooch wrote: I see your point. However, that suggests that the naming of /proc/mounts is wrong. Perhaps we should have a /proc/namespace that shows all these VFS bindings, and separately a list of real mounts. What's "real"? /proc/mounts would better left as it was (funny replacement for /etc/mtab) and there should be something along the lines of /proc/namespace (hell knows, we might make it compatible with /proc/ns from new Plan 9). That something most definitely doesn't need to share the format with /proc/mounts...
Re: FS_SINGLE queries
Alexander Viro writes: On Sat, 10 Jun 2000, Richard Gooch wrote: I see your point. However, that suggests that the naming of /proc/mounts is wrong. Perhaps we should have a /proc/namespace that shows all these VFS bindings, and separately a list of real mounts. What's "real"? /proc/mounts would better left as it was (funny replacement for /etc/mtab) and there should be something along the lines of /proc/namespace (hell knows, we might make it compatible with /proc/ns from new Plan 9). That something most definitely doesn't need to share the format with /proc/mounts... What I mean by "real" mounts is a table that shows how each FS was brought into the namespace (or each namespace, once you implement CLONE_NEWNS). So for example: #device filesystem roots /dev/hda1 ext2/ /dev/hda2 ext2/var/spool/mail /gaol/var/spool/mail noneproc/proc /gaol/proc in /proc/namespace. And I suppose that /proc/namespace would be unique for each namespace as well. This way, no distinction is made between the first mount and subsequent bindings, which is what you'd like, as I gather you'd like to make all bindings equal. Aside: I guess the reality is that the first binding (the original mount -t ext2) is more equal than the subsequent bindings (mount -t bind). Evidence: the O_CREAT bug I found the other day ;-) Regards, Richard Permanent: [EMAIL PROTECTED] Current: [EMAIL PROTECTED]
Re: FS_SINGLE queries
On Sat, 10 Jun 2000, Richard Gooch wrote: What I mean by "real" mounts is a table that shows how each FS was brought into the namespace (or each namespace, once you implement CLONE_NEWNS). So for example: #device filesystem roots /dev/hda1 ext2/ /dev/hda2 ext2/var/spool/mail /gaol/var/spool/mail none proc/proc /gaol/proc Bad format. If anything, it should contain mount IDs (if you want to have union-mount you need those, just to be able to take away components). The following might go: 1 / / ext2/dev/hda1 2 /var/spool/mail / ext2/dev/hda2 3 /proc / procfs 14 /gaol/var/spool/mail/ ext2/dev/hda2 15 /gaol/proc / procfs 42 /gaol/lib/libc.2.1.3.so /lib/libc.2.1.3.so ext2/dev/hda1 ... IOW, ID + mountpoint + location of root in its tree + fs type + fs-specific parameters. That at least allows to reproduce the namespace. And yes, IMO "device" is fs-specific parameter.
Re: FS_SINGLE queries
Alexander Viro writes: On Sat, 10 Jun 2000, Richard Gooch wrote: What I mean by "real" mounts is a table that shows how each FS was brought into the namespace (or each namespace, once you implement CLONE_NEWNS). So for example: #device filesystem roots /dev/hda1 ext2/ /dev/hda2 ext2/var/spool/mail /gaol/var/spool/mail noneproc/proc /gaol/proc Bad format. If anything, it should contain mount IDs (if you want to have union-mount you need those, just to be able to take away components). The following might go: 1 / / ext2/dev/hda1 2 /var/spool/mail / ext2/dev/hda2 3 /proc / procfs 14/gaol/var/spool/mail/ ext2/dev/hda2 15/gaol/proc / procfs 42/gaol/lib/libc.2.1.3.so /lib/libc.2.1.3.so ext2/dev/hda1 ... IOW, ID + mountpoint + location of root in its tree + fs type + fs-specific parameters. That at least allows to reproduce the namespace. And yes, IMO "device" is fs-specific parameter. Yeah, sure. I did say "for example". Your format looks fine. One question: is the mount ID really needed? Can't you distinguish based on what FS you're mounting (and mountpoint root)? BTW: I agree that device is fs-specific. It's much nicer to see "none" done away with. Regards, Richard Permanent: [EMAIL PROTECTED] Current: [EMAIL PROTECTED]
Re: FS_SINGLE queries
Alexander Viro writes: On Sat, 10 Jun 2000, Richard Gooch wrote: Yeah, sure. I did say "for example". Your format looks fine. One question: is the mount ID really needed? Can't you distinguish based on what FS you're mounting (and mountpoint root)? First of all, interface is simpler that way. Will it really make much difference? What would be harder to do without mount IDs? And how much harder? And then... consider the situation when root logs in and decides to mess with luser's namespace. What about it? Avoiding numbers is a good thing. They have no intrinsic meaning. Regards, Richard Permanent: [EMAIL PROTECTED] Current: [EMAIL PROTECTED]
Re: FS_SINGLE queries
On Sat, 10 Jun 2000, Richard Gooch wrote: Will it really make much difference? What would be harder to do without mount IDs? And how much harder? Beware of functions with many arguments... Besides, what about "kill the component of union-mount on /barf NFS-mounted from venus:/foo/bar"? What exactly are you going to pass here? Such stuff is better left to userland. And then... consider the situation when root logs in and decides to mess with luser's namespace. What about it? bastard@venus% su - Password:clickety root@venus% w luser luser pts/0 ... root@venus% ps t pts/0 728 pts/0 ... root@venus% cat /proc/728/ns 123749 /home/luser/foo / nfs whatever root@venus% umount -I 123749 root@venus% logout bastard@venus% mail luser Subject: you've been told to umount ~/foo appropriate verbal abus^Weducation ^D Avoiding numbers is a good thing. They have no intrinsic meaning. Tell that to guys who invented file descriptors. IMO that works quite fine - I'll prefer to do close(17) rather than recalling incantations of horror needed on OS/360shudderingdeciding not to type that stuff late on Saturday
Re: FS_SINGLE queries
Alexander Viro writes: On Sat, 10 Jun 2000, Richard Gooch wrote: Will it really make much difference? What would be harder to do without mount IDs? And how much harder? Beware of functions with many arguments... Besides, what about "kill the component of union-mount on /barf NFS-mounted from venus:/foo/bar"? What exactly are you going to pass here? Such stuff is better left to userland. Let's see. Pass the same stuff you see in /proc/namespace? Instead of cut-and-paste of the mount ID, cut-and-paste the other entries on that line. You're making the decision based on what's in /proc/namespace anyway. Why add another level of indirection? And then... consider the situation when root logs in and decides to mess with luser's namespace. What about it? bastard@venus% su - Password:clickety root@venus% w luser luser pts/0 ... root@venus% ps t pts/0 728 pts/0 ... root@venus% cat /proc/728/ns 123749/home/luser/foo / nfs whatever root@venus% umount -I 123749 root@venus% logout bastard@venus% mail luser Subject: you've been told to umount ~/foo appropriate verbal abus^Weducation ^D Avoiding numbers is a good thing. They have no intrinsic meaning. Tell that to guys who invented file descriptors. IMO that works quite fine - I'll prefer to do close(17) rather than recalling incantations of horror needed on OS/360shudderingdeciding not to type that stuff late on Saturday But FDs are different. You reference the file by name, and the system returns an opaque handle. But the system isn't returning a mount ID as the result of some operation: you had to scan a file for it. So really your handle to the mount is something else, the mount ID is merely another level of indirection. Regards, Richard Permanent: [EMAIL PROTECTED] Current: [EMAIL PROTECTED]
