[opensuse-factory] RFC: Staging driver communication
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi all - One of the things I've seen cropping up lately is the number of bug reports that involve staging drivers. For the uninitiated, staging drivers are drivers that have been included in the kernel but are known to be of insufficient quality to be considered for "true" inclusion. Sometimes drivers in staging are improved and "promoted" to full inclusion and other times they are considered abandoned and are dropped entirely. One common example is the rt2860 driver. When I find the time, which is becoming rarer these days, I try to backport fixes to this driver to the 11.3 kernel since the hardware seems common enough. The issue as I see it is that we have no way to communicate to the user that the driver they're using is of dubious quality. In an ideal world, we could take the bug reports and fix the upstream driver. In reality, most of us don't have the time to tackle improving a driver for hardware we don't have. So, what's the best way to communicate this to the user? Here's my list but I'm open to suggestions: 1) Move staging drivers to a separate package that isn't installed by default 2) Issue a warning during install or first driver load that the driver is of dubious quality 3) Use something like the flags we use in the SLE kernels to document a driver as supported or not to prevent the driver from being loaded without explicitly enabling it (preferably combined with #2) 4) Add a release note documenting which drivers are staging and hope that users actually read it (unlikely) 5) Don't change anything - -Jeff - -- Jeff Mahoney SUSE Labs -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAk1StIYACgkQLPWxlyuTD7LNoQCeLZMvEOfv4dEqeZ5INr8kCFkc y40AoJIdXIZceIIEj7liktJtzSl4+7QY =NaWq -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Wed, Feb 09, 2011 at 10:36:38AM -0500, Jeff Mahoney wrote:
Hi all -
One of the things I've seen cropping up lately is the number of bug reports that involve staging drivers. For the uninitiated, staging drivers are drivers that have been included in the kernel but are known to be of insufficient quality to be considered for "true" inclusion. Sometimes drivers in staging are improved and "promoted" to full inclusion and other times they are considered abandoned and are dropped entirely.
One common example is the rt2860 driver. When I find the time, which is becoming rarer these days, I try to backport fixes to this driver to the 11.3 kernel since the hardware seems common enough.
The issue as I see it is that we have no way to communicate to the user that the driver they're using is of dubious quality. In an ideal world, we could take the bug reports and fix the upstream driver. In reality, most of us don't have the time to tackle improving a driver for hardware we don't have.
So, what's the best way to communicate this to the user? Here's my list but I'm open to suggestions:
1) Move staging drivers to a separate package that isn't installed by default
I wouldn't object to this, but it seems a bit harsh as for some systems, we even support staging drivers to some customers (yeah, I know this doesn't matter to openSUSE, but not all staging drivers are "bad", some are there for a variety of reasons, not the least being I forgot to move them to the "main" portion of the kernel tree...)
2) Issue a warning during install or first driver load that the driver is of dubious quality
That happens already, so you don't have to do anything new here :)
3) Use something like the flags we use in the SLE kernels to document a driver as supported or not to prevent the driver from being loaded without explicitly enabling it (preferably combined with #2) 4) Add a release note documenting which drivers are staging and hope that users actually read it (unlikely) 5) Don't change anything
6) Assign all staging driver bugs to me? thanks, greg k-h -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 02/09/2011 11:07 AM, Greg KH wrote:
On Wed, Feb 09, 2011 at 10:36:38AM -0500, Jeff Mahoney wrote:
Hi all -
One of the things I've seen cropping up lately is the number of bug reports that involve staging drivers. For the uninitiated, staging drivers are drivers that have been included in the kernel but are known to be of insufficient quality to be considered for "true" inclusion. Sometimes drivers in staging are improved and "promoted" to full inclusion and other times they are considered abandoned and are dropped entirely.
One common example is the rt2860 driver. When I find the time, which is becoming rarer these days, I try to backport fixes to this driver to the 11.3 kernel since the hardware seems common enough.
The issue as I see it is that we have no way to communicate to the user that the driver they're using is of dubious quality. In an ideal world, we could take the bug reports and fix the upstream driver. In reality, most of us don't have the time to tackle improving a driver for hardware we don't have.
So, what's the best way to communicate this to the user? Here's my list but I'm open to suggestions:
1) Move staging drivers to a separate package that isn't installed by default
I wouldn't object to this, but it seems a bit harsh as for some systems, we even support staging drivers to some customers (yeah, I know this doesn't matter to openSUSE, but not all staging drivers are "bad", some are there for a variety of reasons, not the least being I forgot to move them to the "main" portion of the kernel tree...)
2) Issue a warning during install or first driver load that the driver is of dubious quality
That happens already, so you don't have to do anything new here :)
I don't mean dumping a short message to the kernel log. I mean real integration into the UI so that the user doesn't have to hunt for it. Toss a message on dbus (or whatever) so it pops up in the GUI.
3) Use something like the flags we use in the SLE kernels to document a driver as supported or not to prevent the driver from being loaded without explicitly enabling it (preferably combined with #2) 4) Add a release note documenting which drivers are staging and hope that users actually read it (unlikely) 5) Don't change anything
6) Assign all staging driver bugs to me?
That works for me. :) - -Jeff - -- Jeff Mahoney SUSE Labs -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAk1SvmIACgkQLPWxlyuTD7IrSwCbBIP3bNQgWU68db3jeVWp2PKD zSUAniKVRHWf2DGOZWSpo1Mt4l6ugaIG =MMJo -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Wed, Feb 09, 2011 at 11:18:42AM -0500, Jeff Mahoney wrote:
On 02/09/2011 11:07 AM, Greg KH wrote:
On Wed, Feb 09, 2011 at 10:36:38AM -0500, Jeff Mahoney wrote:
Hi all -
One of the things I've seen cropping up lately is the number of bug reports that involve staging drivers. For the uninitiated, staging drivers are drivers that have been included in the kernel but are known to be of insufficient quality to be considered for "true" inclusion. Sometimes drivers in staging are improved and "promoted" to full inclusion and other times they are considered abandoned and are dropped entirely.
One common example is the rt2860 driver. When I find the time, which is becoming rarer these days, I try to backport fixes to this driver to the 11.3 kernel since the hardware seems common enough.
The issue as I see it is that we have no way to communicate to the user that the driver they're using is of dubious quality. In an ideal world, we could take the bug reports and fix the upstream driver. In reality, most of us don't have the time to tackle improving a driver for hardware we don't have.
So, what's the best way to communicate this to the user? Here's my list but I'm open to suggestions:
1) Move staging drivers to a separate package that isn't installed by default
I wouldn't object to this, but it seems a bit harsh as for some systems, we even support staging drivers to some customers (yeah, I know this doesn't matter to openSUSE, but not all staging drivers are "bad", some are there for a variety of reasons, not the least being I forgot to move them to the "main" portion of the kernel tree...)
2) Issue a warning during install or first driver load that the driver is of dubious quality
That happens already, so you don't have to do anything new here :)
I don't mean dumping a short message to the kernel log. I mean real integration into the UI so that the user doesn't have to hunt for it. Toss a message on dbus (or whatever) so it pops up in the GUI.
That might be hard when those drivers get loaded in the initrd, like a number of them do today. I have a laptop here that oopses on the latest FACTORY/Tumbleweed kernel because of this issue, I need to get a patch into the next -stable update to resolve it, so I understand the problem, but issuing a dbus message wouldn't help a user out who happens to have a machine that doesn't boot.
3) Use something like the flags we use in the SLE kernels to document a driver as supported or not to prevent the driver from being loaded without explicitly enabling it (preferably combined with #2) 4) Add a release note documenting which drivers are staging and hope that users actually read it (unlikely) 5) Don't change anything
6) Assign all staging driver bugs to me?
That works for me. :)
Seriously, I'm fine with this, assign away. thanks, greg k-h -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 02/09/2011 11:24 AM, Greg KH wrote:
On Wed, Feb 09, 2011 at 11:18:42AM -0500, Jeff Mahoney wrote:
On 02/09/2011 11:07 AM, Greg KH wrote:
On Wed, Feb 09, 2011 at 10:36:38AM -0500, Jeff Mahoney wrote:
Hi all -
One of the things I've seen cropping up lately is the number of bug reports that involve staging drivers. For the uninitiated, staging drivers are drivers that have been included in the kernel but are known to be of insufficient quality to be considered for "true" inclusion. Sometimes drivers in staging are improved and "promoted" to full inclusion and other times they are considered abandoned and are dropped entirely.
One common example is the rt2860 driver. When I find the time, which is becoming rarer these days, I try to backport fixes to this driver to the 11.3 kernel since the hardware seems common enough.
The issue as I see it is that we have no way to communicate to the user that the driver they're using is of dubious quality. In an ideal world, we could take the bug reports and fix the upstream driver. In reality, most of us don't have the time to tackle improving a driver for hardware we don't have.
So, what's the best way to communicate this to the user? Here's my list but I'm open to suggestions:
1) Move staging drivers to a separate package that isn't installed by default
I wouldn't object to this, but it seems a bit harsh as for some systems, we even support staging drivers to some customers (yeah, I know this doesn't matter to openSUSE, but not all staging drivers are "bad", some are there for a variety of reasons, not the least being I forgot to move them to the "main" portion of the kernel tree...)
2) Issue a warning during install or first driver load that the driver is of dubious quality
That happens already, so you don't have to do anything new here :)
I don't mean dumping a short message to the kernel log. I mean real integration into the UI so that the user doesn't have to hunt for it. Toss a message on dbus (or whatever) so it pops up in the GUI.
That might be hard when those drivers get loaded in the initrd, like a number of them do today.
I have a laptop here that oopses on the latest FACTORY/Tumbleweed kernel because of this issue, I need to get a patch into the next -stable update to resolve it, so I understand the problem, but issuing a dbus message wouldn't help a user out who happens to have a machine that doesn't boot.
Most of the staging driver issues I've seen aren't boot-related. The system comes up fine and then some device isn't operating properly. It'd be nice to let the user know that ahead of time. The more I think about, you're right about tossing a message on dbus during boot wouldn't work - -- devices are probably all initialized before the UI comes up. Perhaps a bit of post-processing in a script that runs after xdm. *shrug* - -Jeff - -- Jeff Mahoney SUSE Labs -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAk1SwuYACgkQLPWxlyuTD7I2PgCcDQA1B6frKTavbKjBd/LnI8CB mKUAoJex2yIUAnumoumInKXjjO4rsl4g =Oy9K -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Jeff Mahoney wrote:
The issue as I see it is that we have no way to communicate to the user that the driver they're using is of dubious quality. In an ideal world, we could take the bug reports and fix the upstream driver. In reality, most of us don't have the time to tackle improving a driver for hardware we don't have.
Maybe the model of trying to put everything into a single giant repo needs to be reconsidered upstream already.
So, what's the best way to communicate this to the user? Here's my list but I'm open to suggestions:
1) Move staging drivers to a separate package that isn't installed by default
You'd add the hw ids to the meta data for those packages nevertheless though. So the packages would get installed automatically anyways if the hardware is present.
2) Issue a warning during install or first driver load that the driver is of dubious quality 3) Use something like the flags we use in the SLE kernels to document a driver as supported or not to prevent the driver from being loaded without explicitly enabling it (preferably combined with #2)
A user space driver load/bind interceptor would be nice indeed. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Wed, Feb 09, 2011 at 05:15:21PM +0100, Ludwig Nussel wrote:
Jeff Mahoney wrote:
The issue as I see it is that we have no way to communicate to the user that the driver they're using is of dubious quality. In an ideal world, we could take the bug reports and fix the upstream driver. In reality, most of us don't have the time to tackle improving a driver for hardware we don't have.
Maybe the model of trying to put everything into a single giant repo needs to be reconsidered upstream already.
Um, really? The benifits of keeping the drivers/staging/ tree _in_ the main kernel tree are huge. There is no known advantage of keeping it out, and in fact, that's one of the main reasons I started doing this work. What do you feel would benifit by keeping this separate? How would the work flow happen? How would other distros and users be able to sync up properly?
So, what's the best way to communicate this to the user? Here's my list but I'm open to suggestions:
1) Move staging drivers to a separate package that isn't installed by default
You'd add the hw ids to the meta data for those packages nevertheless though. So the packages would get installed automatically anyways if the hardware is present.
2) Issue a warning during install or first driver load that the driver is of dubious quality 3) Use something like the flags we use in the SLE kernels to document a driver as supported or not to prevent the driver from being loaded without explicitly enabling it (preferably combined with #2)
A user space driver load/bind interceptor would be nice indeed.
What do you mean by this? thanks, greg k-h -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Greg KH wrote:
On Wed, Feb 09, 2011 at 05:15:21PM +0100, Ludwig Nussel wrote:
Jeff Mahoney wrote:
The issue as I see it is that we have no way to communicate to the user that the driver they're using is of dubious quality. In an ideal world, we could take the bug reports and fix the upstream driver. In reality, most of us don't have the time to tackle improving a driver for hardware we don't have.
Maybe the model of trying to put everything into a single giant repo needs to be reconsidered upstream already.
Um, really? The benifits of keeping the drivers/staging/ tree _in_ the main kernel tree are huge. There is no known advantage of keeping it out, and in fact, that's one of the main reasons I started doing this work.
Well, no doubt having a central place for hosting and a shepherd is beneficial. The question is whether all of this needs to be in one git repo/tarball. Comparing apples and oranges the kernel could be viewed like openSUSE Factory with a single .spec file that builds everything. It would be quite hard to maintain leaf packages that way, especially for novices.
What do you feel would benifit by keeping this separate?
You mean who? Me when trying to get a fix for a lirc driver out to the users that don't tumble on weed for example :-) Previously I could just cherry pick fixes from lirc cvs myself, put them into the lirc package and request an update. Now the drivers are in the kernel and I certainly don't want to get involved maintaining patches there.
How would the work flow happen? How would other distros and users be able to sync up properly?
Just like it works with distributions or bigger user space projects that consist of several components. How do GNOME or KDE manage to create working (*cough*) releases? :-)
A user space driver load/bind interceptor would be nice indeed.
What do you mean by this?
Some program that could e.g. ask for confirmation before a module that was never loaded before gets loaded or ask whether a loaded module is allowed to bind to a device not seen before. Like a polkit dialog saying "loading NULL deref prone exoticsocketfamily.ko requires admin authentication". The same mechnism could then be used to require confirmation if staging drivers are requested. Admins could easily train an installation and then lock it down so users can't use arbitrary usb devices. I'm thinking of the recent issue where a mobile phone could pretend to be a keyboard and launch programs when plugged in. On a locked system only a specific usb port would be allowed to have a keyboard connected. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 02/09/2011 12:31 PM, Ludwig Nussel wrote:
Greg KH wrote:
What do you feel would benifit by keeping this separate?
You mean who? Me when trying to get a fix for a lirc driver out to the users that don't tumble on weed for example :-) Previously I could just cherry pick fixes from lirc cvs myself, put them into the lirc package and request an update. Now the drivers are in the kernel and I certainly don't want to get involved maintaining patches there.
I'm not sure why you think this is an issue. Wouldn't http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=history;f... essentially do the same thing?
How would the work flow happen? How would other distros and users be able to sync up properly?
Just like it works with distributions or bigger user space projects that consist of several components. How do GNOME or KDE manage to create working (*cough*) releases? :-)
.. and there's pretty high overhead involved with that. In-kernel drivers have the maintenance benefit that if an API is changed, the changer has to fix all the call sites as well. - -Jeff - -- Jeff Mahoney SUSE Labs -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAk1S0IUACgkQLPWxlyuTD7IADACdG1K4j+FbVM4a3yzJiKCMxu22 JEIAoI4KBC0yt1mWMSqszfIiQvBspqXU =rF0p -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Jeff Mahoney wrote:
On 02/09/2011 12:31 PM, Ludwig Nussel wrote:
Greg KH wrote:
What do you feel would benifit by keeping this separate?
You mean who? Me when trying to get a fix for a lirc driver out to the users that don't tumble on weed for example :-) Previously I could just cherry pick fixes from lirc cvs myself, put them into the lirc package and request an update. Now the drivers are in the kernel and I certainly don't want to get involved maintaining patches there.
I'm not sure why you think this is an issue.
Wouldn't http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=history;f... essentially do the same thing?
Patches would still need to be included in the huge kernel package with all it's special magic and processes though.
How would the work flow happen? How would other distros and users be able to sync up properly?
Just like it works with distributions or bigger user space projects that consist of several components. How do GNOME or KDE manage to create working (*cough*) releases? :-)
.. and there's pretty high overhead involved with that. In-kernel drivers have the maintenance benefit that if an API is changed, the changer has to fix all the call sites as well.
The individual components could still be considered in-kernel. So the policy would apply there as well. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 02/10/2011 03:45 AM, Ludwig Nussel wrote:
Jeff Mahoney wrote:
On 02/09/2011 12:31 PM, Ludwig Nussel wrote:
Greg KH wrote:
What do you feel would benifit by keeping this separate?
You mean who? Me when trying to get a fix for a lirc driver out to the users that don't tumble on weed for example :-) Previously I could just cherry pick fixes from lirc cvs myself, put them into the lirc package and request an update. Now the drivers are in the kernel and I certainly don't want to get involved maintaining patches there.
I'm not sure why you think this is an issue.
Wouldn't http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=history;f... essentially do the same thing?
Patches would still need to be included in the huge kernel package with all it's special magic and processes though.
What special magic and processes? It's submit a patch to lkml and the maintainer and either it's accepted or you get review back. The special magic may be that quality control is quite a bit higher once it's in the mainline kernel.
How would the work flow happen? How would other distros and users be able to sync up properly?
Just like it works with distributions or bigger user space projects that consist of several components. How do GNOME or KDE manage to create working (*cough*) releases? :-)
.. and there's pretty high overhead involved with that. In-kernel drivers have the maintenance benefit that if an API is changed, the changer has to fix all the call sites as well.
The individual components could still be considered in-kernel. So the policy would apply there as well.
This already happens to a certain degree. Subsystem maintainers have their own trees that accumulate fixes and they're ultimately pulled into the mainline repository. As far as keeping entirely separate projects go, that's not going to happen. It's an argument that's already happened and has been settled within the kernel community. The costs totally outweigh the benefits. The kernel community has already decided and documented its position on a stable API, which is essential for having separate projects. Coordinating updates between all of them would be a huge increase in effort for everyone involved and would cripple development. That other projects (like GNOME or KDE) do this is irrelevant. Those projects are designed to be platforms for applications and having a stable API and ABI makes sense. The kernel community's policy is that the right thing to do is to include your driver in the mainline code or suffer the maintenance headaches. Even lack of hardware isn't an excuse as it's an oft-repeated fact that there are drivers in the kernel for which only 4 physical units exist. We have a stable ABI where the kernel interfaces with userspace (sysfs excluded), so we're keeping that part of the bargain. - -Jeff - -- Jeff Mahoney SUSE Labs -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAk1T//MACgkQLPWxlyuTD7JipACeLyTGz4P9LbeIfgRNFvtiODTc NhUAoKhPSpDf+2ThLjMxml0/RF5v/yXt =yFYs -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Thu, Feb 10, 2011 at 10:10:43AM -0500, Jeff Mahoney wrote:
Even lack of hardware isn't an excuse as it's an oft-repeated fact that there are drivers in the kernel for which only 4 physical units exist.
Make that 1 physical unit for some drivers I know about and keep updating.
We have a stable ABI where the kernel interfaces with userspace (sysfs excluded), so we're keeping that part of the bargain.
sysfs is documented and stable, within reason, see Documentation/ABI/ for the details on what you can rely on and use. So we keep that bargain as well, much to my sometime dismay :) thanks, greg k-h -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Jeff Mahoney wrote:
On 02/10/2011 03:45 AM, Ludwig Nussel wrote:
Jeff Mahoney wrote:
On 02/09/2011 12:31 PM, Ludwig Nussel wrote:
Greg KH wrote:
What do you feel would benifit by keeping this separate?
You mean who? Me when trying to get a fix for a lirc driver out to the users that don't tumble on weed for example :-) Previously I could just cherry pick fixes from lirc cvs myself, put them into the lirc package and request an update. Now the drivers are in the kernel and I certainly don't want to get involved maintaining patches there.
I'm not sure why you think this is an issue.
Wouldn't http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=history;f... essentially do the same thing?
Patches would still need to be included in the huge kernel package with all it's special magic and processes though.
What special magic and processes? It's submit a patch to lkml and the maintainer and either it's accepted or you get review back.
I was referring to the downstream side here. I have no interest in getting in touch with kernel-source.rpm.
How would the work flow happen? How would other distros and users be able to sync up properly?
Just like it works with distributions or bigger user space projects that consist of several components. How do GNOME or KDE manage to create working (*cough*) releases? :-)
.. and there's pretty high overhead involved with that. In-kernel drivers have the maintenance benefit that if an API is changed, the changer has to fix all the call sites as well.
The individual components could still be considered in-kernel. So the policy would apply there as well.
This already happens to a certain degree. Subsystem maintainers have their own trees that accumulate fixes and they're ultimately pulled into the mainline repository.
I wonder why though. Wouldn't e.g. a git submodule basically achieve the same thing? cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On 17.2.2011 14:30, Ludwig Nussel wrote:
Jeff Mahoney wrote:
On 02/10/2011 03:45 AM, Ludwig Nussel wrote:
Patches would still need to be included in the huge kernel package with all it's special magic and processes though.
What special magic and processes? It's submit a patch to lkml and the maintainer and either it's accepted or you get review back.
I was referring to the downstream side here. I have no interest in getting in touch with kernel-source.rpm.
The magic is documented here: http://en.opensuse.org/openSUSE:Kernel_git#Submitting_your_changes_to_the_ke... and it consist of pushing your patch upstream and _nothing more_. Our kernel will eventually be updated to the latest 2.6.X.Y release without your intervention. Michal -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
participants (4)
-
Greg KH -
Jeff Mahoney -
Ludwig Nussel -
Michal Marek