I see that it can be done both ways, and yours requires far less currently
non-existent infrastructure.
That non-existent infrastructure would be nice to have someday anyway, so that
we can handle keyword searching that returns multiple hits, etc. Not a short
term project though, and I am not expecting it of you....
Hans
Alexander Viro wrote:
>
> 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