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-next>] [day] [month] [year] [list]

Message-ID: <32793.192.54.193.51.1170248792.squirrel@rousalka.dyndns.org>
Date:	Wed, 31 Jan 2007 14:06:32 +0100 (CET)
From:	"Nicolas Mailhot" <nicolas.mailhot@...oste.net>
To:	greg@...ah.com
Cc:	linux-kernel@...r.kernel.org
Subject: Re: Free Linux Driver Development!

Hi,

I'd really love if the same offer was extended to GPL out-of-tree driver
trees.

There are many out-of-tree drivers (ivtv, lirc, various webcam drivers,
enhanced USB keyboard handlers...) with merging not planified or taking
ages.

The associated hardware is useful enough someone wrote a driver.
There is "documentation" in the form of a working driver.
Sometimes there are already many FLOSS apps writen that depend on them.

Yet they languish out-of-tree, effectively sterilizing alternative efforts
just because people know they exist. Someone wrote an howto on how to plug
them in an ancient kernel, and that's good enough to remove a lot of the
merging incentive.

The common wisdom seems to be their authors will hammer LKML hard enough
the driver will eventually be merged. But these authors:
- get set in their ways like any human being
- usually put new features first and merging last
- may have decided merging was too much work
- may be struggling to do it alone
- may have asked LKML about merging once, got ignored/refused (for good,
bad, or obsolete reasons), and decided to spend their time on more
constructive work

So there are many reasons why merging will not happen as things stand.

These drivers are in many ways every bit as harmful as closed binary blobs
(making users miserable, killing alternatives, being a major reason old
kernel binaries get used long after security problems were identified and
fixed, etc). Merging/reworking them is easier than starting from
incomplete NDAed documentation. If (as this offer implies) there are good
driver authors waiting to do more drivering, why aren't those a priority?

As a side effect, cleaning up our own GPL community mess would help
convince hardware manufacturers working within the main kernel is the
right workable solution.

Regards,

-- 
Nicolas Mailhot

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