Messages in this thread | | | From | (H. Peter Anvin) | Subject | Re: [PATCH] root-hopping for pre-2.3.41-3 | Date | 25 Jan 2000 13:15:34 -0800 |
| |
Followup to: <Pine.LNX.4.10.10001251214350.1212-100000@penguin.transmeta.com> By author: Linus Torvalds <torvalds@transmeta.com> In newsgroup: linux.dev.kernel > > d_path() can easily be made to yield something else: in particular, we > already have the "(deleted)" semantics in /proc/<pid>/fd to show that a > name is not actually necessarily valid, and the same goes for things that > are not actually reachable from the root. > > I don't think device numbers are all that helpful. And in fact I think > that if it shows any of the "unattached" filesystems at all, it's probably > a bug in the first place - after the root hop, the old root should not > show up. > > Finally, as to the umount / new system call issue: I really think that the > root hopping should be a special event, not a re-mount or a umount, but > more of a "global chroot()" system call. I agree with making it possible > to re-mount from user space, but I don't agree with overloading an > existing call that does something completely different. >
I would like to suggest an alternate system call with, perhaps, more useful semantics:
pivot_root("new_root", "old_root");
This will detach the path "new_root" and turn it into the new root, and *then* attach the *old* root, now detached, to the path "old_root", which must be a valid mount point (i.e. directory) in the new root.
For example, say that you have a ramdisk (initrd) as root, and you just mounted your intended root at /newroot. You could then do:
mkdir("/newroot/initrd"); pivot_root("/newroot", "/initrd");
/* Now the initrd is mounted at /initrd, and the new root is / */
/* Do stuff that involves the initrd */
umount("/initrd"); /* Done with it */
-hpa -- <hpa@transmeta.com> at work, <hpa@zytor.com> in private! "Unix gives you enough rope to shoot yourself in the foot."
- 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/
| |