On Wed, 1 Mar 2000, Khimenko Victor wrote:
> > Sigh... http://inferno.bell-labs.com/plan9/vol2.html. Notice the stuff
> > under "Namespaces". Authors: group of little-known BTL guys, some
> > Thompson, Ritchie, Pike...
> >
> This is all great and flashy but I'm not sure if we can do somthing like
> this without rewriting of each and every program in system. And I've not
> found there answer on simple question: "how this all great picture will
> keep up when old innocent unix program will call chroot("/home/username") ?"
Read again. Hint: if no process does rfork() (== clone()) with the right
flag (don't share namespace) they behave as on classical UNIX. Your
program (and it's _not_ innocent if it plays with chroot - it should at
the very least care about preparing the environment) should do
namespace-splitting clone() and _mount_ (while it still has UID==0) ipcfs
at /ipc. After chroot, right. Nobody else will ever see the thing mounted
there - namespace is exactly what builds a unified tree from the
individual filesystems. On any UNIX. The whole idea is to make it a
per-process resource. That can be shared or copied upon clone(), just as
every other resource does (mm, descriptors, signals, etc. - it's hardly a
new idea). Default (i.e. what fork() does) is unusual - it's share instead
of copy. As on any UNIX - you have trees from individual filesystems and
you know how they are glued into the unified tree. Just that idea of that
gluing may be different for different sets of processes. It's _not_ an
extensive change to our architecture. We need to scratch
->d_covers/->d_mounts and replace the logics regarding the crossing of
mountpoints. We also need some trickery wrt sharing files across
namespace-splitting clone() (esp. opened directories), but that's
solvable. My main problem with doing full-blown namespaces is that I don't
want to spend couple of months _after_ this change fixing nasty races.
I'ld rather get dcache/namei into the robust form before that. And that's
what made me seriously unhappy about devfs addition - it makes things
trickier. Oh, well...
Victor, RTFManpages (on the same site) and look through our
namespace-related code. It's not that horrible change. BTW, some ideas we
got from there include: procfs, dcache and... devfs. Read their
documentation through - we all owe those guys that much. Really. They had
proven that they _have_ taste - basic API designed by them works 30 years
later and is used by literally all living decent systems. That's something
one can be proud of. Really. It's not about replacing everything with
Plan 9 - I don't want it. But there are very good design ideas that fit
well into UNIX semantics and were unclaimed since neither USL nor BSD
branches had enough infrastructure in the kernel. WE HAVE IT. We have
superior VFS design - best of all Unices I've seen or heard of. Thanks to
the work of Linus, Bill Hawes, Schobel-Theuer and a lot of other people.
We are in unique position - we can incorporate the good ideas of Plan 9
_without_ dropping compatibility with UNIX. Something that was deemed
inpractical by BTL folks, BTW. It would be a fscking shame if we blew it.
-
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 : Tue Mar 07 2000 - 21:00:09 EST