-----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