Le mercredi 31 janvier 2007 à 12:12 -0800, Greg KH a écrit : > On Wed, Jan 31, 2007 at 02:06:32PM +0100, Nicolas Mailhot wrote: [Reordering for the sake of argument] > > There are many out-of-tree drivers (ivtv, lirc, various webcam > > drivers, > > enhanced USB keyboard handlers...) with merging not planified or taking > > ages. > > See my above comment about lirc. As for the others, everyone knows > where we are at, and what the critera is for getting their code into the > tree, so it's not like we are hiding anywhere :) The perception of many out-of-tree projects is "if I try to get in-tree I'll be submitted to vicious review, and I'll have to fix the code my myself, and that's assuming someone bothers to review it at all". What you've just wrote is no different: > we will gladly take any > currently out-of-the-tree drivers into mainline, as long as they follow > our rules and coding style issues, please do so. In other words, getting an out-of-tree driver in is a major unrewarding work commitment for its author (especially considering that if he was familiar with good kernel coding, chances are he'd have worked in-tree from the start, with an experimental driver) Contrast it with "give us a partial NDAed spec and we'll write a driver from scratch for you". You're asking way more of people that have a lot less resources than hardware manufacturers. Many of those projects did try to get in-tree at least once before giving up. > > I'd really love if the same offer was extended to GPL out-of-tree driver > > trees. > > This kind of offer has _always_ been there for out-of-tree GPL drivers. > I have contacted many different groups and driver authors over the years > to offer my help in trying to get their code into the mainline kernel. > > Some take me up on the offer, others ignore it, and still others activly > refuse to do so, saying they want to stay out-of-the tree (lirc is one > of these examples...) And when resources were scarce respecting this kind of decision was the right thing. But if there are enough resources for your offer, I question letting whole classes of drivers we have documentation for (in the form of code) out-of-tree (even if that means some less-than-amiable forking). Both the OLPC and the N800 have toy (webcam) video capabilities. The logical next spec (next hardware generation) is stronger video with remoting (someone will probably sell remote add-ons before). Are they going to lack in-tree support just because the reference framework is out-of-tree, and we respect its authors' wishes so much nothing can happen till they change their mind ? (And that's assuming they're dead-set on being out-of-tree. Like I wrote before they're not getting the same deal you're offering to hardware manufacturers) Meanwhile you're asking for specs of hardware no Linux user has, because no form of Linux support ever existed. This is a strange use of resources. Regards, -- Nicolas Mailhot
Attachment:
signature.asc
Description: Ceci est une partie de message =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=
- Follow-Ups:
- Re: Free Linux Driver Development!
- From: Greg KH <[email protected]>
- Re: Free Linux Driver Development!
- References:
- Re: Free Linux Driver Development!
- From: "Nicolas Mailhot" <[email protected]>
- Re: Free Linux Driver Development!
- From: Greg KH <[email protected]>
- Re: Free Linux Driver Development!
- Prev by Date: Re: [PATCH 3/7] barrier: a scalable synchonisation barrier
- Next by Date: Re: [RFC PATCH] 20-rc6-mm3: kernel/params.c: compile fail when CONFIG_SYSFS not set
- Previous by thread: Re: Free Linux Driver Development!
- Next by thread: Re: Free Linux Driver Development!
- Index(es):