Subject: Re: [vserver] vserver git server and misc. thoughts
From: Herbert Poetzl <herbert@13thfloor.at>
Date: Tue, 12 Aug 2008 20:35:00 +0200

On Tue, Aug 12, 2008 at 10:00:16AM -0500, Adam Majer wrote:
> Remigiusz Modrzejewski wrote:
> > But in the end, it would invariably mean a lot of work, swinging patches back 
> > and forth and convincing people that you're right about this code. And it 
> > would probably end up being accepted in less than 100%. Then, Herbert 
> > explicitly stated that maintaining 80% in-tree and 20% out-tree is exactly 
> > the thing he's trying to avoid...
> > 
> > Anyways, you're welcome to try. And it would be a great thing if you 
> > succeeded.
> 
> 80% in-tree and 20% out-tree is much better than 100% out tree.
> 
> I don't understand the argument that this would be worse. It will
> *never* happen that 100% of the patch will go into the kernel tree in
> one linux release, or even 2 or 3. I've seen that already with a driver
> ivtv. First they needed to implement necessary kernel API and get that
> included. Then the driver started moving into the kernel. It took about
> about a dozen kernel releases to get all the stuff in there, but it is
> done now.
> 
> This is how kernel development works - small changes. This is why
> monolithic patches like grsecurity, PaX or vserver can't be accepted.
> Patches have to come in some kind of a logical sequence.

let me just give an example here, and you might want to
check that with google and friends ...

 2001/01 linux 2.4.0 is released with the new '--bind' mount feature

 2003/07 I discovered that certain mount options (like read only)
         do not have any effect on --bind style mounts [1]
         (i.e. they are silently ignored) and thus I proposed a 
         solution to lkml
 2003/08 I also proposed a similar patch for 2.6.0 as soon as it
         was available (as it showed the same misbehaviour) [2]

 2005/03 the bind mount extensions (short bme) reached a state
         where we considered inclusion into Linux-VServer, as they
         had been available (and been used) for more than a year

 2005/12 vs2.1.0 is released, including bme by default [3]

 2006/02 I gave up on trying to get this fixed in mainline

 2006/06 Dave Hansen proposes a reworked version for -mm [4]

 2007/05 The n-th rewrite and resubmission [5]

 2008/02 Dave Hansen submits the n-th version which is acked or
         signed off by almost any involved kernel devel

 2008/07 2.6.26 is the first kernel to provide RO bind mounts
         (but with a twist, i.e. you need to do a mount and
         a remount to get the desired functionality) 
 
 [1] http://osdir.com/ml/file-systems/2003-08/msg00005.html
 [2] http://linux.derkeiler.com/Mailing-Lists/Kernel/2003-08/1741.html
 [3] http://archives.linux-vserver.org/200512/0244.html
 [4] http://lkml.org/lkml/2006/6/27/562
 [5] http://lkml.org/lkml/2007/5/14/228

the bottom line is: this defect (not a feature) required more
than 5 years and the efford from several people, including
the IBM folks to get 'worked around' because it is still not
'fixed' :)

> Now if we get vserver into the kernel, you will not see a lot of kernel
> changes that would break vserver per-say. This also mean that vserver
> would have to use standard API for most of the isolation instead of
> intrusive patches.

there are no standard APIs for what we need, and there are no
intrusive Linux-VServer patches ...

here from my slides: http://vserver.13thfloor.at/Stuff/slide-page16.png
note that the last line, the patch-2.6.23(delta) is the
difference between two consecutive kernel releases (2.6.22 and 2.6.23)

HTC,
Herbert

> - Adam