> 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@stusta.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@imap.cc
> Bonn, Germany
> Diese Nachricht besteht zu 100% aus wiederverwerteten Bits.
> Ungeÿÿffnet mindestens haltbar bis: (siehe Rÿÿckseite)
