Subject: Re: [GIT PATCH] more Driver core patches for 2.6.19
Newsgroups: gmane.linux.kernel
Date: 2006-12-13 21:32:50 GMT (2 years, 29 weeks, 8 hours and 12 minutes ago)
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.