I'd also like to voice my opinion against this "way that linux works".
Drivers should be seperate modules.
If the kernel is always changing in a way that makes drivers incompatible, then THAT's the problem. And this is the kind of stuff that makes linux impossible to get mainstream usage...
It all feels like there are no standards to follow and everyone just do whatever they want instead of working cooperatively. I don't know much about decisions that made linux what it is today, but why didn't anyone make a standard driver interface for linux yet? The way PC hardware works doesn't change all that much, so why is the kernel way of comunicating with hardware doing so?
Before people start flaming me or just saying "you're free to do so yourself", well, I don't have the time to do so, and maybe not the skills either.
~end of probably uneducated rant
The enterprise and LTS distros are really the counterpart to Windows, not the fast moving ones.
It probably helps if you think about the fast moving distros as a view into the enterprise distros coming a year or two from now, which *will* have a stable driver interface.
Last edited by bridgman; 09-20-2009 at 09:53 PM.
I believe having separate drivers is just something one misses when one wants desperately to get a Windows way of managing its system, but I find it hardly necessary.
In fact, not having to check around several vendors to get driver updates is actually nice.
OK, I'm certainly no expert on the matter, but AFAIK, Solaris has such a driver interface, and mostly positive things came out of it. For Linux that would mean more manufacturers, who are not able/willing to open source their code, offering Linux drivers.
"Get your driver in the kernel" is an extremely naive suggestion; do you see NVidia or AMD being able or willing to get their binary blobs opened and included in the kernel? (Those are just two examples, there are many more.) Also, except of being naive, the suggestion can turn out to be deceptive: after opening up the drivers, there's a very big chance of "we won't push this crap code into the kernel" response. Or no one is actually willing to include the driver; Marvell opened up their ethernet driver at some point (GPL), but no one ever has put it in the kernel; to this day, the "sky2" kernel driver is still used even though it has bugs. They expect Marvell to do it.
So companies not only have to get all the legalese and paperwork solved to open their drivers, they also have to work extra to actually adapt it for kernel inclusion. Yeah sure, "open up the specs so we can write drivers." They open the specs, no one writes drivers. Then, "open up the source code for your drivers." Er, OK, we gave you the specs, you didn't write any drivers, so fine, here's the freaking source code, take it. Oh noes, no one includes it in the kernel... "Rewrite your driver and beg on LKML for acks". There's only one response really: "Screw you. I'm out. I'm not prepared to waste ten times more resources for a market ten times smaller."
I don't blame them the least for not doing all the above. It's not worth the effort. And Linux isn't helping them even though according to simple logic, it should (they don't need Linux; Linux needs *them*).
This situation is the main reason I think that a major part of "The Linux Kernel Driver Interface" document is bollocks and Greg Kroah-Hartman not really thinking before writing. The technical reasons seem logical though.
Last edited by RealNC; 09-21-2009 at 02:59 AM.
Please. Yes, there is a lot of work going into those graphics drivers, so I can understand where they're coming from. But the general rule is that drivers aren't that big a deal, the graphics market is the rare exception here.do you see NVidia or AMD being able or willing to get their binary blobs opened and included in the kernel? (Those are just two examples, there are many more.)
If the code really is crap, then why would you want to run it as a binary blob?Also, except of being naive, the suggestion can turn out to be deceptive: after opening up the drivers, there's a very big chance of "we won't push this crap code into the kernel" response.