Subject: Re: [vserver] vserver git server and misc. thoughts
From: Adam Majer <adamm@zombino.com>
Date: Thu, 14 Aug 2008 11:17:56 -0500

Christian Balzer wrote:
> Hello,
> 
> On Wed, 13 Aug 2008 23:56:46 +0200 Herbert Poetzl wrote:
>> On Wed, Aug 13, 2008 at 10:17:30PM +0200, Gildas wrote:
> [...]
>>> My question is simple though maybe a bit harsh: what future is left to
>>> vservers? Does it makes sense to keep it as a separate project? What
>>> does vservers support that is missing (or will be missing/absent) from
>>> the container solution? Can it be merged?  
>> once the Linux-VServer functionality is completely
>> covered by mainline kernels my job is done, and
>> Linux-VServer will only remain as userspace tools
>> (most likely util-vserver) maintained by Daniel or
>> somebody else ....
>>
>> I have no problem with that whatsoever! :)
>>
> I had the feeling/impression that this was going to be your sentiment on
> that. ;)
> 
> I guess my question in turn would be: When? At what point do you or
> anybody with the necessary insight into kernel development envision this
> to happen? And yes, can it be merged, as in, can the process being sped up
> by moving VServer bits into the kernel that are not being addressed by
> current container efforts?

VServer will not move into Linux tree by us contacting Linus (unless
Linus is a big fan of vserver and just itching to get it into the
kernel) or necessarily posting stuff on their vger mailing list. How it
works is through current maintainers of Linux's subsystems. They have to
accept the patches into their trees and then these are then pushed out
to Linus' tree and then these become released kernels. And it takes A
LONG time. Just look at how long it took SMART capability to be added to
SATA driver. It was experimental for like 10 releases!

Regardless, *no one* in the kernel will look at vserver patches if we
have it as a .diff or some tarball of patches. They work with their tool
(GIT atm) and want to be able to simply merge some of outside patches.


> I (well, the people that feed me) will need IPV6 capable VServers (or an
> equivalent) by the end of next year for example. And I venture the
> clamoring by people for it to work with newer kernels is at least
> partially driven by the need to support very recent hardware.

Not necessarily. If vserver is behind in porting, the job to port
becomes harder as the mainline kernel changes.

- Adam