[lkml]   [2000]   [Jan]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH] root-hopping for pre-2.3.41-3

On Tue, 25 Jan 2000 wrote:
> I'm sending you a patch for pre-2.3.41-3 that allows the use of chroot to
> change the root directory from an initrd or similar to a mounted file
> system, and to cleanly unmount the former root. This is much cleaner than
> the current "change_root on exit from linuxrc" magic, and it also allows
> again the use of NFS-root with parameter selection at run time.


I like the thought, but I don't like much of the implementation.

I'd prefer:

- your MNT_DETACH thing is a "umount" flag, and I think that is
fundamentally flawed. It's a separate operation entirely. If we want to
root-hop, what we should do is rather simple:

- detach the trees and haev two trees. This is not the same as
"umount" at all, this is really just

struct dentry *mnt = dentry_lookup("new_root_path");
struct dentry *covered = mnt->d_covers;

mnt->d_covers = mnt; /* New root, no longer covering anything */
covered->d_mounts = covered; /* Old mount-point, no longer attached */

and you're done. You now have two trees, neither of which has
really been unmounted.

- Now that the old root has been detached, NOW you can just try to
unmount it: it's a perfectly regular unmount() at this point, and it
will fail if it is busy.

I don't think your "complicate the normal umount with new flags" approach
is needed at all.

Also, /proc/mounts should just use the dentry and the path lookup function
(d_path()) to create the /proc/mounts output on-the-fly, and that will get
the name right whatever happens (_including_ a rename of the whole
mount-point path, which neither the current approach nor your approach
gets right at all.


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

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