linux-kernel - Re: Free Linux Driver Development!

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <1170278120.21878.48.camel@rousalka.dyndns.org>
Date:	Wed, 31 Jan 2007 22:15:20 +0100
From:	Nicolas Mailhot <nicolas.mailhot@...oste.net>
To:	Greg KH <greg@...ah.com>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: Free Linux Driver Development!

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

Download attachment "signature.asc" of type "application/pgp-signature" (198 bytes)