lkml.org 
[lkml]   [2004]   [Apr]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [hsflinux] [PATCH] Blacklist binary-only modules lying about their license
Date
viro@parcelfarce.linux.theplanet.co.uk writes:

> On Thu, Apr 29, 2004 at 08:40:53PM +0200, Giuliano Colla wrote:
>> As an end user, if I buy a full fledged modem, I get some amount of
>> proprietary, non GPL, code which executes within the board or the
>> PCMCIA card of the modem. The GPL driver may even support the
>> functionality of downloading a new version of *proprietary* code into
>> the flash Eprom of the device. The GPL linux driver interfaces with it,
>> and all is kosher.
>> On the other hand, I have the misfortune of being stuck with a
>> soft-modem, roughly the *same* proprietary code is provided as a binary
>> file, and a linux driver (source provided) interfaces with it. In that
>> case the kernel is flagged as "tainted".
>>
>> But in both cases, if the driver is poorly written, because of
>> developer's inadequacy, or because of the proprietary code being poorly
>> documented and/or implemented, my kernel may go nuts, be it tainted or not.
>>
>> Can you honestly tell apart the two cases, if you don't make a it a case
>> of "religion war"?
>
> Yes. *Especially* outside of religious wars - while fuckup capabilities
> of Joe Random Driver Monkey are unlimited, there is a difference between
> the impact of fuckups in the code that runs on CPU and in the code that
> runs on peripherial. If nothing else, the latter is less likely to try
> anything cute and tricky with locking.
>
> In other words, with code running on the host CPU lusers have much, much
> more ways to luse, luse again when trying to "fix" things and make it
> harder to figure out what had caused the bloody mess.

But they could make just as big a mess if they released the source
code, right? And it would be just as hard to know which driver to
blame. IF you manage to isolate the fault to one driver, it's
probably easier to see what it's doing, and possibly fix it if the
code is open. Some driver code I've seen is so messy that it doesn't
really make a difference if you have the code or not.

Don't get me wrong now. I much prefer open source drivers. Those can
be compiled on any architecture (unless stupid bugs prevent that,
which I've seen many cases of) and with the newest kernel releases.

--
Måns Rullgård
mru@kth.se

-
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/

\
 
 \ /
  Last update: 2005-03-22 14:02    [W:1.652 / U:0.104 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site