[ubuntu-x] Status of kernel X drivers

Stefan Bader stefan.bader at canonical.com
Fri Feb 19 10:01:47 UTC 2010


Bryce Harrington wrote:
> On Thu, Feb 18, 2010 at 03:41:24PM -0600, Steve Conklin wrote:
>> Backport the entire drm stack from .33 to Lucid.
>>
>> After release and if needed, create a lbm package to deliver .34 or .35
>>
>> With support from the X side, I think that this is a good solution.
> 
> This is essentially option 2 that we discussed yesterday.  The
> discussion on #dri-devel greatly lessens my concern about risk levels
> for this option.  That they have been focusing on stabilization on
> 2.6.33 is very encouraging.
> 
> There may be some changes needed on the X side, but I think it's
> doable and I think it should not be a problem supporting this.
> 
> I mentioned the con for option #1 was the quantity of backporting
> needed.  The discussion on #dri-devel underscores this.
> 
> From apw's Kernel Summary, about why we are going with 2.6.32:
> 
>   The primary decision for the kernel team at UDS is to choose the base
>   kernel version for the release.  For Lucid this will be 2.6.32.  This
>   version has just released providing the maximum stabalisation time, it
>   also is expected to be the kernel of choice for long term releases
>   from other distributions.[1]

Being on 2.6.32 with Lucid and having all/most distributions on the same kernel
and as a result this being the next stable tree which gets longer term support
from Greg, it is hard to predict the exact moves of the in kernel parts.
We benefit from it by getting combined effort stable updates for the kernel, but
 if the stable tree itself will not take on heavily changing backports, then
mainenance with us having 2.6.33 drm in the kernels gets more complicated.

> If other distros are pulling the 2.6.33 drm on top of their 2.6.32 for
> their long term releases as sounds like is the case[2], then this would
> be a fairly significant divergence on our part for no real gain.

Another good point on the LBM (or whatever external package) approach is that we
have stronger control on what this includes. Upstream stable might or might not
follow newer drm and we likely want to follow the common stable tree as much as
possible.

Stefan

> Bryce
> 
> 1: https://lists.ubuntu.com/archives/kernel-team/2009-December/007948.html
> 2: http://cvs.fedoraproject.org/viewvc/rpms/kernel/F-12/drm-upgrayedd.patch?view=log
> 





More information about the kernel-team mailing list