lkml.org 
[lkml]   [2000]   [Jan]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [PATCH] root-hopping for pre-2.3.41-3
Date
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/

\
 
 \ /
  Last update: 2005-03-22 13:56    [W:0.068 / U:0.880 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site