[EMAIL PROTECTED] (Herbert Poetzl) writes: >> Thoughts/comments > > what about alternative solutions, like using pivot_root
I think that pivot_root(2) is a poor solution as you will run into the following problems: * who will unmount the old filesystem? You will need something in the hostile vserver-root doing this... * output/errormessages of the startup-sequence will be impossible, as you will have to remove any references to the old /dev/pts/*, logfiles or /dev/null. Therefore, unmounting of the old '/' will be impossible for vserver usage. 'mount --rbind /vservers/... /' is a better way: it does not make the old filesystem visible in the vserver (with pivot_root, it would be somewhere in the vserver) so the first problem disappears. > or having tagged mounts (i.e. mounts accessible for or visible to > processes which have a special flag set) > > I guess we should move away from what we have now, get some distance, > and think about what we want to have in let's say half a year (or > maybe a year) then start to work in that direction ... Defining a 'vc_merge_namespace(xid_t)' operation (putting the vserver-mounts behind the current ones) would be a solution, but the exact semantic is complicated. You will have to make sure that this syscall happens in a new namespace; I do not know if it is possible that this syscall creates the new namespace itself (current namespace creation is coupled with a process creation). Perhaps, 'vc_merge_namespace()' could do an implicit 'clone(..., CLONE_NEWNS)'? Enrico _______________________________________________ Vserver mailing list [EMAIL PROTECTED] http://list.linux-vserver.org/mailman/listinfo/vserver
