Re: Stable Linux-Vserver patch plans
On Wed, May 27, 2009 at 10:36:53PM -0400, Micah Anderson wrote:
>
> Hi,
>
> I wanted to start a discussion about the plans for the stable kernel
> in the next point release, specifically where it relates to the
> Linux-Vserver patch-set.
>
> As we all know, the 2.6.26 kernel is the version that Lenny ended up
> with and the Linux-Vserver patch that was under development (and was
> still highly experimental and not complete) at that time was *not*
> released for that kernel, and so the version of the patch that Debian
> used was a backport of a snapshot of where things were at the latest
> point.
>
> It was decided by the Linux-Vserver project to do long-term maintenance
> of the 2.6.27 patches, to coincide with the long-term maintenance of
> mainline 2.6.27. The reasons why this situation arose was related to the
> heavy virtualization changes in upstream kernel, causing major patch
> changes.
>
> As a result of this unfortunate timing situation, the remains in the
> Lenny kernel some significant issues that continually come up in
> upstream support channels, as well as in the Debian BTS. The main
> problem is the wrong filesystem attributes being used which cause major
> grief for people switching to or from that kernel. However there are a
> number of other issues that are also significant:
>
> - the missing TB scheduler
> - the PID 1 parent being wrong (initpid)
> - netnamespace (not a big deal, as it is broken in 2.6.26 mainline
> anyway, so it cannot really be used)
> - signalling fix (delta-sigkill-fix01.diff)
> - memory info (delta-cached-fix01.diff)
>
> Most of these issues could be solved by backporting the Linux-Vserver
> patches to resolve them to 2.6.26, leaving only the mainline 2.6.26
> issues.
>
> So I am writing to ask what we can do to fix these issues, if the issues
> were backported, could we get them included in a point release? Or are
> there other plans that would resolve these problems? With a diff against
> mainline, this could be sorted out, but I don't know if such work would
> be used?
hey Micah,
Each issue needs to be considered on its own merit - how important is
the fix and what is the risk of regression. I think the best way to
start would be to file a bug for each issue of >= important severity
and attach a patch.
--
dann frazier
Reply to: