Date:	Tue, 30 Oct 2007 01:29:17 +0100
From:	Tilman Schmidt <tilman@...p.cc>
To:	Adrian Bunk <bunk@...nel.org>
CC:	Greg KH <greg@...ah.com>, Simon Arlott <simon@...e.lp0.eu>,
	Chris Wright <chrisw@...s-sol.org>,
	linux-kernel@...r.kernel.org,
	linux-security-module@...r.kernel.org,
	Jan Engelhardt <jengelh@...putergmbh.de>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andreas Gruenbacher <agruen@...e.de>,
	Thomas Fricaccia <thomas_fricacci@...oo.com>,
	Jeremy Fitzhardinge <jeremy@...p.org>,
	James Morris <jmorris@...ei.org>,
	Crispin Cowan <crispin@...spincowan.com>,
	Giacomo Catenazzi <cate@...ian.org>,
	Alan Cox <alan@...rguk.ukuu.org.uk>
Subject: Re: eradicating out of tree modules

Am 28.10.2007 20:25 schrieb Adrian Bunk:
> On Sun, Oct 28, 2007 at 07:51:12PM +0100, Tilman Schmidt wrote:
>> Am 28.10.2007 02:55 schrieb Adrian Bunk:
>>> Justifying anything with code with not GPL compatible licences has zero 
>>> relevance here.
>>>
>>> And there's value in making life harder for such modules with 
>>> questionable legality. As an example, consider people who experienced 
>>> crashes of "the Linux kernel" caused by some binary-only driver.
>>> Not that uncommon e.g. with some graphics drivers.
>>> This harms the reputation of Linux as being stable.
>> You are mixing up several distinct categories here: "out of tree"
>> != "non-GPL" != "proprietary" != "of questionable legality" !=
>> "binary-only" != "causing kernel crashes".
> 
> "binary-only non-GPL out-of-tree module causes kernel crashes" is a 
> quite common pattern for some popular binary-only modules.

Common, yes. Popular, maybe. The only one, not. Taking that as reason
for breaking out-of-tree open source modules is throwing out the baby
with the bathwater.

>>> The solution is not to support proprietary drivers, the solution is to 
>>> get open source replacements.
>> So how do you propose to "get" those replacements? And what shall
>> users do during the time this "getting" may take?
> 
> They should swamp the hardware vendors with requests for releasing 
> hardware specifications.

They are doing that already. But somehow it fails to magically cause
open source drivers to spring into existence immediately. The crucial
word here is *time*.

> Or even better buy their hardware from a competitor.

Hmmm. "Your existing hardware isn't supported anymore, buy new one?"
I thought that was a Microsoft line. (SCNR)

>>> If it's low quality code doing something useful - well, how many hundred 
>>> people are on Greg's list only waiting for some driver they could write?
>> No idea. Obviously not enough to actually solve the problem.
> 
> Greg has just begins with getting this started.

Exactly. Again, the problem is time. Deliberately breaking external
modules now and promising an in-tree alternative for later leaves
users out in the cold. That won't do much to improve the reputation
of Linux.

>> What solution do you propose?
> 
> You list the drivers you currently have in mind at the Linux Driver 
> Project [1].

They are all there already.

> Noone proposed to make the existance of out-of-tree modules completely 
> impossible - but it is a fact that derives directly from the Linux 
> kernel development model that thre's no stable API for out-of-tree 
> modules, and therefore each new kernel breaks many of them.

Granted.

> Once you accept this fundamental fact there's not much point in arguing 
> that changes that break out-of-tree modules should be fewer.

Granted. But that's not the point I was arguing anyway.

There is still a point in arguing that breaking out-of-tree modules
is not a goal. It's acceptable collateral damage if there is a good
reason for a change, but it doesn't by and in itself constitute such
a reason. That's why I'm taking exception with your statement in
<20071024223124.GI30533@...sta.de>:
> [...] even though it might sound harsh breaking 
> external modules and thereby making people aware that their code should 
> get into the kernel is IMHO a positive point.

Breaking external modules is *not* positive. It's acceptable, but
everything else being equal it's still better to avoid it.

>>> Let me repeat that Greg has said he has hundreds of volunteers for such 
>>> tasks.
>> Even with hundreds of volunteers, your proposed solution of just
>> rewriting *all* external code in a way fit for inclusion into the
>> kernel is an unachievable goal. Just look at the list on
>> http://linuxdriverproject.org/twiki/bin/view/Main/OutOfTreeDrivers
>> and try to answer why each of them is still out of tree.
>> Hint: In most cases it's neither out of malice nor stupidity on
>> the authors' part.
> 
> There are different problems why different drivers are not (yet) 
> included in the kernel, but which ones don't have any possible solution?

I'm convinced all of them have possible solutions. The challenge
is to turn a possible solution into an actual one. And again, the
problem is time.

> And if you compare the numbers you'll see that Greg has on average a 
> handful of volunteers for one driver.

Not every problem can be solved faster by throwing more people at
it. Take mISDN as an example. Its developers have stated the goal
of inclusion in the main kernel tree years ago and it's still not
there. Deliberately breaking this external module "to make people
aware that their code should get into the kernel" would only delay
this goal even more. But sending them a handful of new volunteers
now would probably constitute the proverbial "adding manpower to a
late project".

> The most important question is still:
> 
> Why should there always be out-of-tree code that fills a real need not 
> satisfied by any in-tree code?

Because every in-tree code starts as out-of-tree code, so as long
as there's development at all there's always a certain amount of
code which isn't in-tree yet - or of which it isn't even sure yet
whether it will get in-tree.

HTH

-- 
Tilman Schmidt                          E-Mail: tilman@...p.cc
Bonn, Germany
Diese Nachricht besteht zu 100% aus wiederverwerteten Bits.
Ungeöffnet mindestens haltbar bis: (siehe Rückseite)


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

Powered by blists - more mailing lists