[Vserver] [vserver-inclusion] Update: 1c milestone reached, and a changed summary

From: Sam Vilain <sam.vilain_at_catalyst.net.nz>
Date: Tue 07 Feb 2006 - 09:40:38 GMT
Message-ID: <43E86B16.4010109@catalyst.net.nz>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Greetings all,

I am happy to announce that the vserver-inclusion project is making
progress. Today I have reached stage 1c) on the patch reshaping plan
(see attached). The patch plan (likely to be used for the LKML
announcement) has had some LKML flintstones removed, too ;-).

~ root@ken:~# cat /proc/virtual/info
~ VCIVersion: 0002:0001
~ VCISyscall: 236
~ VCIKernel: 07000000

Currently the kernel boots, and basic information is available in
/proc/virtual and /proc/XXX/vinfo. There are no features yet, just
infrastructure.

The current patches, against Linus's linux-2.6 tree (probably apply
mostly cleanly to 2.6.16-rc2) are at:

~ http://utsl.gen.nz/vserver/patches-split/mine/2.6.16-rc2%2bgit-vsi/

The next stage will be to bring in the debugging and history support to
the code base, and to make sure that nothing important is missing.

Finally, we will need a test suite demonstrating each feature working,
using util-vserver or libvserver or even a pure[*] Perl implementation.
I hope to have this established in a very basic form before submission
to LKML.

Contributions at this point are probably only useful from experienced
kernel/vserver developers who know how the vserver patch works, and are
able to check that the code there matches their expectations.
Experienced vserver/userspace developers could help out with the test suite.
- --
Sam Vilain, Catalyst IT (NZ) Ltd.

* - the term 'pure' applied to a Perl built-in like syscall() just seems
~ wrong ;)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFD6GsR/AZAiGayWEMRArmoAJ9HalHvBY0juclclqZABBT5ShpcEQCgrR34
fe4/V6iKy0UHES22P8BVlwk=
=zUY4
-----END PGP SIGNATURE-----

The mighty Linux-VServer inclusion branch =========================================

The Goal
--------
To reshape the Linux-VServer kernel patch into a series of patches
that incrementally add features, for inclusion into the mainstream
Linux 2.6 tree.

This will be done on a feature-based basis, and debate is encouraged
into the exact form of the plan and implementation.

The name of this feature is potentially up for debate (Jails?
Containers? Domains? Contexts?); but the term "vserver" is already
in the kernel - so 'changing' that would probably need a good reason
and be approved by the core team.

Some features might not be dependent on vserver per se, of course.
This will likely be uncovered as individual features are merged.

Minor nitpicking like naming conventions are taken from the
Linux-VServer.org branch, and constructive suggestions on that front
are most welcome. Preferably in the form of patches or a git source I
can pull :)

The Plan
--------
Patches, by general category, with a rough expected order; very hazy
dependencies between the general categories follow.

0. features that don't need vserver, but are in the patch anyway

  a. Bind Mount Extensions (mount --bind -o ro)
  b. Kernel split (already included upstream! and with incorrect
     acknowledgement ;))

1. core vserver patch - no features

  a. struct and ps addition; internal API and refcounting
  b. syscall, and switch
  c. /proc visibility

** UP TO HERE **

  d. debugging
  e. history

2. isolation features

  a. IPC, semaphore, and signal restrictions
  b. proc/array filtering
  c. IPv4 chbind
  d. FS chroot() barrier
  e. general /proc filtering
  f. ptrace
  g. process admin: alloc_uid, find_user, sys_setpriority
  h. printk
  i. kthread

3. virtualisation features

  a. uts information
  b. initpid virtualisation
  c. uptime
  d. load average
  e. ksyslog
  f. vshelper (reboot support)
  g. vroot (quota, fs IOCTL, etc)
  i. general PID virtualisation (eric's patch)
  j. ngnet (network stack virtualisation)

4. resource tracking features

  a. scheduler tracking hook
  b. FS xid counting
  c. FS xid tagging
  d. ulimit
  e. RSS usage
  f. IO - async tracking

5. resource sharing features

  a. scheduling v1 - TBF and vavavoom
  b. FS - immutable linkage invert (immulink)
  c. disk scheduler integration
  d. RSS limits
  e. FS - mad cow
  
6. resource limit features

  a. scheduler
  b. rlimits
  c. disklimits

Locations
---------

The GIT repository for this project is at:

  http://utsl.gen.nz/vserver/vserver.git

The patch stack for this project will be on the "vserver-inclusion"
branch; it is exported to:

  http://utsl.gen.nz/vserver/patches-split/mine/2.6.N+git-vsi/

Where 2.6.N was the last release (or release candidate) of Linus'
tree. This patch is NOT against any release you can download as a
tarball :).

Upstream (13thfloor.at) patches will be on the "vs2.1.x.y" branch,
corresponding to their version number. The "upstream" patch that was
used as a source will be under:

  http://utsl.gen.nz/vserver/patches-split/13thfloor/2.6.N-vs2.1.x.y/

And, for sanity checking, the result of my importing of the upstream
quilt patch into stgit and re-exporting the branch via stgit will be
at:

  http://utsl.gen.nz/vserver/patches-split/mine/2.6.N-vs2.1.x.y/

The file sizes may be a lot smaller from STGIT; it does not repeat
filename info for each hunk like Quilt does, but if you diff the diffs
you'll hopefully see the differences are minor.

This file is http://utsl.gen.nz/vserver/patch-plan.txt

gitweb coming soon.

Acknowledgements / Plug
-----------------------

Many thanks to Herbert for picking up maintenance and development of
VServer, and championing the 2.6 port. Full credits are at:

  http://linux-vserver.org/Hall+of+Fame

Also, thanks go out to Catalyst IT (NZ) Limited for sponsoring my time
on this project.

  http://www.catalyst.net.nz/

Much kudos should go to Alexey on his fantastic branch; from which
there has been much cross-pollination of ideas and code. Eric's work
on vpid is excellent too, but that seems a bit of a taboo topic right
now. So, we'll defer judgement there for now. It's a fairly higher
order feature; who knows - we might even find some clever way to not
need it by that point.

_______________________________________________
Vserver mailing list
Vserver@list.linux-vserver.org
http://list.linux-vserver.org/mailman/listinfo/vserver
Received on Tue Feb 7 09:41:26 2006

[Next/Previous Months] [Main vserver Project Homepage] [Howto Subscribe/Unsubscribe] [Paul Sladen's vserver stuff]
Generated on Tue 07 Feb 2006 - 09:41:31 GMT by hypermail 2.1.8