On Wed, 7 Jun 2000, Hans Reiser wrote:
> chdir might be better. There is a deep VFS lacking, which is that it cannot
> resolve names that return multiple files, and a minor aspect of that is that
No, there is not.
> chdir() cannot change to multiple directories. This will be a hard one to
> rectify though, as it requires a whole new set of system calls alongside the
> current ones.
No, it doesn't. With the current data structures we can easily have
different namespaces for different processes - just have separate vfsmount
trees for them. Then chdir() will do the right thing for each - resolve to
the directory that corresponds to the name in caller's namespace. No new
syscalls needed - just consider a namespace as a process attribute (as we
already do with memory context, table of opened files, etc.) and allow to
specify whether you want to share or create a private copy upon clone()
(again, same as we already have for other resources, but unlike them
default should be "share", not "copy"). mount(2) and umount(2) will modify
caller's namespace (and thus be visible to everyone who shares the
namespace with caller). You don't need anything new - the only things we
are currently missing to support the thing are:
additional code in exit() (if we were the last owner of our
namespace - umount everything in that namespace and destroy the structure
itself).
additional code in mntput() (if we are releasing the last
reference to struct vfsmount - do the equivalent of remove_vfsmnt()).
additional code in fork() (if CLONE_NEWNS is passed - copy the
vfsmount tree and switch ->rootmnt, ->pwdmnt and ->altrootmnt to the
new copies of respective vfsmounts).
That's it. No magic, no new syscalls.
-
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/
This archive was generated by hypermail 2b29 : Thu Jun 15 2000 - 21:00:15 EST