Re: [Vserver] [ANNOUNCE] vserver-inclusion project

From: Herbert Poetzl <herbert_at_13thfloor.at>
Date: Thu 02 Feb 2006 - 11:03:21 GMT
Message-ID: <20060202110321.GC24264@MAIL.13thfloor.at>

On Thu, Feb 02, 2006 at 10:32:00PM +1300, Sam Vilain wrote:
> Hey folks,
>
> Some good news - I am currently working on getting vserver included
> upstream. Attached is the plan, and links to the work-in-progress.

just for the record, I'm 'officially' supporting
the idea and will help Sam whenever my time permits.

here a few comments to a 'mainline' merge though:

 - we should try to make virtualization in the kernel
   as general as possible, while keeping the overhead
   as small as feasible

 - we should strive to allow competitive solutions
   to utilize the virtualization in a sensible manner
   (I'd hate to see linux-vserver-only code in mainline)

 - many things will not be merged in a year or two,
   so do not expect the vserver patches to go away
   too soon, but hopefully they will get smaller and
   smaller (if this succeeds)

well, that's it!

best,
Herbert

> Currently I'm of the opinion that I should finish section 1 and get a
> minimal userland test suite running before sending it off to LKML for
> savaging by the hoards; however what is there already is the minimum
> that Linus was after for considering the patch.
>
> If anyone has any process suggestions or objections, please raise them
> on the list now. If you would like to contribute, getting savvy with
> something like StGIT (see http://www.procode.org/stgit/) will help us
> work together.

[Content-Description: It's the plan, Stan.]

> 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. To do so without requiring the core Linux VServer
> team to compromise on their primary objectives or waste time
> maintaining the umpteen different kernel versions this process will
> create. And finally, to do so without drifting from the core patch so
> much it makes lots more work for Herbert.
>
> The Plan
> --------
>
> Note that the dependency order of these patches is not strictly
> linear; however git is not in a position to apply patch calculus, so
> this is probably hard information to extract :)
>
> All revisions will be committed with Herbert's name as the Author
> rather than myself, though technically I am the author of those
> revisions, Herbert is the real author of the work.
>
> Patches, by general category, with a rough expected order:
>
> 0. features that don't need vserver, but are in the patch anyway
>
> a. Bind Mount Extensions (mount --bind --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
>
> ** UP TO HERE **
>
> b. syscall, and switch
> c. /proc visibility
> 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
> c. uptime
> d. load average
> e. ksyslog
> f. vshelper (reboot support)
> g. vroot (quota, fs IOCTL, etc)
> i. general PID virtualisation
> 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
>
> Acknowledgements / Plug
> -----------------------
>
> Other than the whole VServer crew, thanks go out to Catalyst IT (NZ)
> Limited for sponsoring my time on this project.
>
> http://www.catalyst.net.nz/

> _______________________________________________
> Vserver mailing list
> Vserver@list.linux-vserver.org
> http://list.linux-vserver.org/mailman/listinfo/vserver

_______________________________________________
Vserver mailing list
Vserver@list.linux-vserver.org
http://list.linux-vserver.org/mailman/listinfo/vserver
Received on Thu Feb 2 11:04:04 2006

[Next/Previous Months] [Main vserver Project Homepage] [Howto Subscribe/Unsubscribe] [Paul Sladen's vserver stuff]
Generated on Thu 02 Feb 2006 - 11:04:24 GMT by hypermail 2.1.8