Mailinglist Archive: opensuse-kernel (77 mails)

< Previous Next >
Re: [opensuse-kernel] Re: [opensuse-factory] Hardware enablement in kernel updates
  • From: Jeff Mahoney <jeffm@xxxxxxxx>
  • Date: Tue, 15 Dec 2009 13:36:37 -0500
  • Message-id: <4B27D735.5020204@xxxxxxxx>
Hash: SHA1

On 12/15/2009 01:09 PM, Larry Finger wrote:
On 12/15/2009 11:44 AM, Jeff Mahoney wrote:
Hash: SHA1

On 12/15/2009 12:20 PM, Larry Finger wrote:
On 12/14/2009 07:09 PM, Jeff Mahoney wrote:

I think this is a good idea. The current policy heavily penalizes the
user whose hardware was supported by the kernel that was released just
after the distro was frozen. Most of my activity is with wireless
drivers, which have many changes with each kernel release, as well as
manufacturers releasing new hardware on a regular basis.

For me, kernel 2.6.32 is much more usable than 2.6.31 because one of my
devices is a Broadcom BCM4312. It must be said, however, that the
changes needed to support that chip are likely to be too invasive to fit
under your guidelines. That will be the hardest part of implementing the
proposed changes - how invasive can the changes be?

Does your proposed new policy automatically exclude those drivers in

I'm not sure what you mean here. Do you mean updating staging/ drivers
or adding new ones? I have no problem adding new staging/ drivers. They
definitely fit the "standalone" requirement.

The question really was whether your phrase "mainline drivers" included
those in "staging". From what you say below, it obviously does.

I don't have any objections to revving staging/ drivers in general. Most
changes will only improve their quality. I don't really want to say
that it will happen automatically, though. That ends up being quite a
lot of work for kernel teams that are already heavily overloaded.

OTOH, now that we have a public git repo, I wouldn't be opposed
accepting pull requests that rev staging drivers. There are a lot of
things we could end up doing that we haven't in the past if we have more
community involvement.

With git, the pull from staging shouldn't cause the kernel teams too
much effort to get them to build. The fact that driver is in staging
removes a lot of guarantees. In addition, those drivers are generally in
better shape than the initial version of the vendor's driver, which is
likely the user's only other option. At least this is true for Realtek's
rtl8187se driver.

Well, "too much effort" is relative. Our kernel teams are currently
doing maintenance for multiple code streams as well as developing SLE11
SP1 and openSUSE 11.3. I'm sure you can imagine where backporting the
staging drivers falls on the list of priorities.

Pulling direct from mainline doesn't work since our git repo isn't an
expanded tree. It's a repository of patches that get applied in
sequence. Backporting the drivers means manually cherry picking out the
changes and rolling them into patches that apply to our tree. This makes
it painful for things like this, but has _huge_ advantages in other areas.

What I meant by accepting pull requests is that if someone finds a
driver that has changes that fixes an issue they're observing on their
own hardware and wants to put the effort into backporting the patch into
their own copy of our git repo, I wouldn't be opposed to accepting it
into our repo.

- -Jeff

- --
Jeff Mahoney
SuSE Labs
Version: GnuPG v2.0.12 (GNU/Linux)
Comment: Using GnuPG with SUSE -

To unsubscribe, e-mail: opensuse-kernel+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: opensuse-kernel+help@xxxxxxxxxxxx

< Previous Next >