[PATCH][CFT] per-process namespaces for Linux

Alexander Viro (viro@math.psu.edu)
Sat, 24 Feb 2001 23:16:10 -0500 (EST)


He's back. And this time he's got a chainsaw.

Yes, folks. We got per-process namespaces. Working. With proper
behaviour on exit(), yodda, yodda. Enjoy. Help with testing would be more
than welcome.

Current patch is on ftp.math.psu.edu/pub/viro/namespaces-S2.gz
It's against 2.4.2.

Contents:
* proper refcounting of struct super_block
* GC for vfsmounts (finally)
* fix for races between get_super() and umount()
* SMP-safe lock_super()
* general cleanup of fs/super.c
* "lazy" option for umount() (detach from mountpoint now, do the
rest when it will cease to be busy - use MNT_DETACH in 'flags' argument
to get that behaviour).
* Plan 9 per-process namespaces (sans unions so far)
* large cleanup of boot process (ramdisk handling, etc.)

Variant without namespaces (they were the last part) is in the same
directory, called s_lock-S2.gz.

rfork.c (in the same place) will copy a namespace and start shell in it.
Use for testing... It's an equivalent of rfork(RFNAMEG) on Plan 9.

One detail - patch requires ramfs built into the kernel (boot process cleanup
part needs that).

It works here (ran for about 12 hours with no problems). It's _NOT_ for
inclusion into 2.4. Some pieces might go (get_super() races have to be
fixed, after all), but most of this stuff is 2.5 fodder. However, it
seems to be working. No doubt there are bugs and it's far from being
a final version. I would call it _very_ early beta. Please, help with
testing.

Comments on the code/design/amount of dope it took to write the thing (zero,
actually) are welcome. I _will_ document it, but it's still not in the
final form. Pretty close to it, hopefully, but...

I'm more than willing to answer questions on the design of the thing - just
ask. So far that's the best I can do - all documentation is a pile of notes
+ CVS log.

Cheers,
Al
PS: hopefully - back for good.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/