FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Ubuntu > Ubuntu Kernel Team

 
 
LinkBack Thread Tools
 
Old 02-18-2010, 09:40 PM
Bryce Harrington
 
Default Status of kernel X drivers

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]

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.

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

--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team
 
Old 02-18-2010, 10:17 PM
Bryce Harrington
 
Default Status of kernel X drivers

On Fri, Feb 19, 2010 at 09:30:07AM +1100, Christopher James Halse Rogers wrote:
> > I'd agree. Plus it'll be easier to explain "we're carrying 2.4.18 minus
> > patch foo".
> >
> > Which is the commit(s) that needs reverted?
>
> libdrm would need b496c63143e9a4ca02011582329bce2df99d9b7c and I think
> also 88e8a8bbaf026aa10225880001ab7ca1c392168a reverted.

Wow, that first one is definitely a pretty significant api bump!

> If we're comfortable with pulling from the nouveau kernel tree[1] for
> linux-backports-modules-nouveau, then going over the API bump would
> indeed make cherry-picking and backporting fixes easier. The API bump
> hasn't made it out of that tree yet, as far as I'm aware.

Hrm, that kind of sucks. But it does seem like digesting the change now
would be easier than getting painted into a corner and have to pull it
in post-release or something messy like that.

However, maybe it'd make sense to let the kernel drm 2.6.33 backporting
stuff get settled out first? So put in libdrm 2.4.18 without these two
patches for alpha-3 so we'll have the fixes for testers, and then after
a3 is out do the API update?

Bryce

--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team
 
Old 02-18-2010, 10:52 PM
Christopher James Halse Rogers
 
Default Status of kernel X drivers

On Thu, 2010-02-18 at 15:17 -0800, Bryce Harrington wrote:
> On Fri, Feb 19, 2010 at 09:30:07AM +1100, Christopher James Halse Rogers wrote:
> > > I'd agree. Plus it'll be easier to explain "we're carrying 2.4.18 minus
> > > patch foo".
> > >
> > > Which is the commit(s) that needs reverted?
> >
> > libdrm would need b496c63143e9a4ca02011582329bce2df99d9b7c and I think
> > also 88e8a8bbaf026aa10225880001ab7ca1c392168a reverted.
>
> Wow, that first one is definitely a pretty significant api bump!
>
> > If we're comfortable with pulling from the nouveau kernel tree[1] for
> > linux-backports-modules-nouveau, then going over the API bump would
> > indeed make cherry-picking and backporting fixes easier. The API bump
> > hasn't made it out of that tree yet, as far as I'm aware.
>
> Hrm, that kind of sucks. But it does seem like digesting the change now
> would be easier than getting painted into a corner and have to pull it
> in post-release or something messy like that.
>
> However, maybe it'd make sense to let the kernel drm 2.6.33 backporting
> stuff get settled out first? So put in libdrm 2.4.18 without these two
> patches for alpha-3 so we'll have the fixes for testers, and then after
> a3 is out do the API update?

That would be fine. It would require a DDX update, as there have been
more #define renames in libdrm since the snapshot we currently have was
cut, but this is only a build-time requirement, not a runtime problem.

We need a new upload of the DDX anyway, to fix the
linux-backports-modules-nouveau depends (which currently point to
linux-backports-modules-nouveau-2.6.32-12-generic), and possibly work
out where the initramfs hook goes.


--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team
 
Old 02-19-2010, 09:01 AM
Stefan Bader
 
Default Status of kernel X drivers

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
>


--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team
 
Old 02-21-2010, 10:20 PM
Ben Hutchings
 
Default Status of kernel X drivers

On Thu, 2010-02-18 at 14:40 -0800, Bryce Harrington wrote:
[...]
> 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]
>
> 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.
[...]
> 2: http://cvs.fedoraproject.org/viewvc/rpms/kernel/F-12/drm-upgrayedd.patch?view=log

Fedora has been backporting drm (and nouveau) for a long time but it's
not so clear what means for RHEL.

I think this is something we will also consider doing in Debian. A year
from now I expect nv to be dead and radeon UMS to be removed upstream,
making it impractical to backport new hardware support. Given that, the
maintenance burden for 2.6.33 drm should be lower. But this is really
outside my area of expertise and certainly not my decision to make.

We should probably also consider what this means for drm on the
2.6.32-stable branch. Should the drm developers still send patches
there as well, where applicable? If all the distributions using 2.6.32
use the backported drm, should we ask Greg K-H to pull that?

Ben.

--
Ben Hutchings
73.46% of all statistics are made up.
--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team
 
Old 02-21-2010, 10:20 PM
Ben Hutchings
 
Default Status of kernel X drivers

On Thu, 2010-02-18 at 14:40 -0800, Bryce Harrington wrote:
[...]
> 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]
>
> 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.
[...]
> 2: http://cvs.fedoraproject.org/viewvc/rpms/kernel/F-12/drm-upgrayedd.patch?view=log

Fedora has been backporting drm (and nouveau) for a long time but it's
not so clear what means for RHEL.

I think this is something we will also consider doing in Debian. A year
from now I expect nv to be dead and radeon UMS to be removed upstream,
making it impractical to backport new hardware support. Given that, the
maintenance burden for 2.6.33 drm should be lower. But this is really
outside my area of expertise and certainly not my decision to make.

We should probably also consider what this means for drm on the
2.6.32-stable branch. Should the drm developers still send patches
there as well, where applicable? If all the distributions using 2.6.32
use the backported drm, should we ask Greg K-H to pull that?

Ben.

--
Ben Hutchings
73.46% of all statistics are made up.
 
Old 02-22-2010, 11:38 AM
Martin Pitt
 
Default Status of kernel X drivers

Hey Bryce,

Bryce Harrington [2010-02-18 10:34 -0800]:
> On Thu, Feb 18, 2010 at 10:38:07AM -0500, Chase Douglas wrote:
> > I believe it would
> > be useful for users to have the option through jockey to install backport
> > modules, with all the disclaimers of level of support.
>
> That's not a bad idea. I was wondering myself how we'd expose the
> availability of new lbm bits to end users, and this approach seems quite
> sensible.

This is actually pretty tricky to do. Usually Jockey advertises device
drivers based on particular hardware in the system. lbm lumps together
an unspecified and unknown set of drivers, so it is hard to describe
it with particular terms to users, except for a very generic "new
drivers, might break your system or not doing anything at all".

lbm could be changed to create a separate "lbm-modaliases" package,
similar to nvidia-current-modaliases. Jockey uses those lists (e. g.
/usr/share/jockey/modaliases/nvidia-current) to map hardware
(identified by modalias) to driver packages and handlers (a handler is
a bit of Python which provides some glue, description, and detection
for a driver package in Jockey terms).

So the options are:

(1) Write a very simple Jockey handler which does not hardware
detection at all, and always advertises lbm as a handler.

(2) Split out lbm-modaliases to reflect what drivers are actually in
lbm, and keep the package description up to date throughout
Lucid's lifetime, and use the package description as the driver
description in Jockey (which is the default if the Jockey handler
doesn't provide its own).

For usability and stability reasons I do not recommend (1) at all, and
in fact would veto it with my desktop tech lead hat on. It's too
error prone if people enable lbm on random boxes without knowing what
it does, due to the entire concept of how lbm is built. As far as I
understood, lbm was mostly a vehicle for asking users in bug reports,
and OEMs?

Martin
--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team
 
Old 02-22-2010, 03:20 PM
Eric Anholt
 
Default Status of kernel X drivers

On Sun, 21 Feb 2010 23:20:14 +0000, Ben Hutchings <ben@decadent.org.uk> wrote:
> On Thu, 2010-02-18 at 14:40 -0800, Bryce Harrington wrote:
> [...]
> > 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]
> >
> > 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.
> [...]
> > 2: http://cvs.fedoraproject.org/viewvc/rpms/kernel/F-12/drm-upgrayedd.patch?view=log
>
> Fedora has been backporting drm (and nouveau) for a long time but it's
> not so clear what means for RHEL.
>
> I think this is something we will also consider doing in Debian. A year
> from now I expect nv to be dead and radeon UMS to be removed upstream,
> making it impractical to backport new hardware support. Given that, the
> maintenance burden for 2.6.33 drm should be lower. But this is really
> outside my area of expertise and certainly not my decision to make.
>
> We should probably also consider what this means for drm on the
> 2.6.32-stable branch. Should the drm developers still send patches
> there as well, where applicable? If all the distributions using 2.6.32
> use the backported drm, should we ask Greg K-H to pull that?

Not sure that gregkh would go along with it, but agreed on the other
points, and maybe if distro folks ask for a backport pull instead of
upstream developers we'll have a better chance of success.

The Intel guys should continue sending patches for the current stable
branch. I've seen a bunch of non-Intel folks requesting pulls of
additional drm/i915 patches to stable branches, so hopefully that can
cover 2.6.32 caretaking once our process moves on to the next stable
kernel.
 
Old 02-22-2010, 03:20 PM
Eric Anholt
 
Default Status of kernel X drivers

On Sun, 21 Feb 2010 23:20:14 +0000, Ben Hutchings <ben@decadent.org.uk> wrote:
> On Thu, 2010-02-18 at 14:40 -0800, Bryce Harrington wrote:
> [...]
> > 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]
> >
> > 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.
> [...]
> > 2: http://cvs.fedoraproject.org/viewvc/rpms/kernel/F-12/drm-upgrayedd.patch?view=log
>
> Fedora has been backporting drm (and nouveau) for a long time but it's
> not so clear what means for RHEL.
>
> I think this is something we will also consider doing in Debian. A year
> from now I expect nv to be dead and radeon UMS to be removed upstream,
> making it impractical to backport new hardware support. Given that, the
> maintenance burden for 2.6.33 drm should be lower. But this is really
> outside my area of expertise and certainly not my decision to make.
>
> We should probably also consider what this means for drm on the
> 2.6.32-stable branch. Should the drm developers still send patches
> there as well, where applicable? If all the distributions using 2.6.32
> use the backported drm, should we ask Greg K-H to pull that?

Not sure that gregkh would go along with it, but agreed on the other
points, and maybe if distro folks ask for a backport pull instead of
upstream developers we'll have a better chance of success.

The Intel guys should continue sending patches for the current stable
branch. I've seen a bunch of non-Intel folks requesting pulls of
additional drm/i915 patches to stable branches, so hopefully that can
cover 2.6.32 caretaking once our process moves on to the next stable
kernel.
--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team
 
Old 02-24-2010, 08:42 PM
Julien Cristau
 
Default Status of kernel X drivers

On Sun, Feb 21, 2010 at 23:20:14 +0000, Ben Hutchings wrote:

> Fedora has been backporting drm (and nouveau) for a long time but it's
> not so clear what means for RHEL.
>
> I think this is something we will also consider doing in Debian. A year
> from now I expect nv to be dead and radeon UMS to be removed upstream,
> making it impractical to backport new hardware support. Given that, the
> maintenance burden for 2.6.33 drm should be lower. But this is really
> outside my area of expertise and certainly not my decision to make.
>
For radeon it seems clear that we need the 2.6.33 code or stay with UMS,
and nouveau is not in .32, so basically the question seems to be about
i915. My impression is that 2.6.32 was quite bad, and 2.6.32.x has
gotten it into a better shape (except for 8xx, but that's been broken
for quite a while, and not just with kms, so...). Now if we're
confident that either i915 in 2.6.33 is better than .32.9 already or
that the regressions it introduces can be fixed in the next month or
couple of months, then backporting drm from .33 seems like it would be a
good thing to do for squeeze.

Cheers,
Julien
 

Thread Tools




All times are GMT. The time now is 06:34 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org