Subject: Re: [vserver] vserver git server and misc. thoughts
From: Herbert Poetzl <herbert@13thfloor.at>
Date: Fri, 15 Aug 2008 23:40:33 +0200

On Thu, Aug 14, 2008 at 11:17:56AM -0500, Adam Majer wrote:
> 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.

you know that 99% of the patches submitted to LKML are
diffs and they have to be inline so that everybody can
look at them without any special tools?

JFYI,
Herbert

> > 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