linux-kernel - Re: [GIT PATCH] more Driver core patches for 2.6.19

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

Date:	Wed, 13 Dec 2006 13:32:50 -0800
From:	Martin Bligh <mbligh@...igh.org>
To:	Greg KH <gregkh@...e.de>
Cc:	"Michael K. Edwards" <medwards.linux@...il.com>,
	Linus Torvalds <torvalds@...l.org>,
	Andrew Morton <akpm@...l.org>, linux-kernel@...r.kernel.org
Subject: Re: [GIT PATCH] more Driver core patches for 2.6.19

Greg KH wrote:
> On Wed, Dec 13, 2006 at 12:38:05PM -0800, Michael K. Edwards wrote:
>> Seriously, though, please please pretty please do not allow a facility
>> for "going through a simple interface to get accesses to irqs and
>> memory regions" into the mainline kernel, with or without toy ISA
>> examples.
> 
> Why?  X does it today :)

Umm ... and you're trying to use the current X model for a positive
example of what we should be doing? that's ... interesting.

>> Embedded systems integrators have enough trouble with chip vendors who
>> think that exposing the device registers to userspace constitutes a
>> "driver".
> 
> Yes, and because of this, they create binary only drivers today.  Lots
> of them.  All over the place.  Doing crazy stupid crap in kernelspace.

So let's come out and ban binary modules, rather than pussyfooting
around, if that's what we actually want to do.

It comes down to a question of whether we have enough leverage to push
them into doing what we want, or not - are we prepared to call their
bluff?

The current half-assed solution of chipping slowly away at things by
making them EXPORT_SYMBOL_GPL one by one makes little sense - would
be better if we actually made an affirmative decision one way or the
other. And yes, I know which side of that argument you'd fall on ;-)

> Again, X does this today, and does does lots of other applications.
> This is a way to do it in a sane manner, to keep people who want to do
> floating point out of the kernel, and to make some embedded people much
> happier to use Linux, gets them from being so mad at Linux because we
> keep changing the internal apis, and makes me happier as they stop
> violating my copyright by creating closed drivers in the kernel.

I don't see how this really any different than letting them create
GPL shims to export data to binary modules (aside from all the legal
wanking over minutae details, which really isn't that interesting).

M.

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