On Sun, Oct 28, 2007 at 07:51:12PM +0100, Tilman Schmidt wrote:
quoted text
> 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.

And noone except the vendor of this module can debug and fix it.

Include more than one binary-only module into your kernel and the number 
of people being able to debug it might drop to zero.

quoted text
> > 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.

Or even better buy their hardware from a competitor.

quoted text
> > 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.

quoted text
> What solution do you propose?

You list the drivers you currently have in mind at the Linux Driver 
Project [1].

quoted text
> >> [D]o you think the world would
> >> be a better place if all the existing out-of-tree modules
> >> just ceased to exist, without any replacement?
> > 
> > With your "without any replacement" you needlessly excluded the 
> > reasonable solution:
> > 
> > The solution is that someone other than the author either takes the 
> > existing external code or rewrites it from scratch, submits it for 
> > inclusion into the kernel, and maintains it there.
> 
> My "without any replacement" is just a description of reality.
> All current external code I am aware of continues to exist only
> because there is no in-kernel replacement.
> 
> Again: how do you propose to bring that solution of yours to pass,

You list the drivers you currently have in mind at the Linux Driver
Project [1].

quoted text
> how long do you think it will take, and what do you propose current
> users of out-of-tree modules do in the meantime?

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.

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

quoted text
>...
> > 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?

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

quoted text
> Of course in-tree code is always better than out-of-tree code. But
> I maintain there will always be out-of-tree code (modules, drivers,
> whatever) that fills a real need not (though hopefully, just not
> yet) satisfied by any in-tree code. All I'm asking for is that you
> take a pragmatic stance with regard to that: not going to any great
> lengths to support it, but acknowledging its existence and
> legitimacy - and not inciting to deliberately break it.

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?

Not everything might have worked in an ideal way in the past, but let's 
try to fix the problem, not let the problem justify workarounds.

quoted text
> Thanks,
> Tilman

cu
Adrian

[1] http://linuxdriverproject.org

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

-
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/