Should Linux Have a Binary Kernel Driver Layer? 944
zerojoker writes "The discussion is not new but was heated up by a blog entry from Greg Kroah-Hartman: Three OSDL Japan members, namely Fujitsu, NEC and Hitachi are pushing for a stable Kernel driver layer/API, so that driver developers wouldn't need to put their drivers into the main kernel tree. GKH has several points against such an idea." What do you think?
If it means more drivers! (Score:0, Insightful)
Comment removed (Score:5, Insightful)
Bad (Score:3, Insightful)
Don't go there, it protects Linux from getting tripped up, and devalues any hardware that doesn't support Linux.
Don't underestimate the important of driver support for Linux, you practically can't make any server component without a good solid Linux driver.
Amen! (Score:4, Insightful)
No (Score:5, Insightful)
It also precludes anyone else from fixing bugs in the broken, half assed crap most corporates spit out these days.
of course it should (Score:5, Insightful)
would it really hurt so much to guarantee a stable DKI? doesn't have to freeze the whole kernel, just a subset of functions that will be guaranteed to work as they do now in perpetuity.
backwards compatibility is just as important to driver writers as it is to app writers.
doesn't even have to be binary backwards compatible, source level would be sufficient for most.
Stability like that leads to stagnation and death (Score:5, Insightful)
Continual refactoring is worth far more than some supposed binary API which prevents changes. Get rid of binary drivers! If companies are so paranoid that they want binary drivers, then the hell with them. Linux can advance better without that baggage.
Re:No Thanks! (Score:3, Insightful)
As the article says, it's illegal, and a bad idea (Score:5, Insightful)
What people tend to forget about this is that it's a bad idea- from most every perspective.
The Linux kernel was written as a Free Softwate alternative to the existing *nix systems.
We have thousands of drivers in the kernel from a combination of development efforts. Sometimes a driver is written by an independant kernel developer, and sometimes it's written from the company producing the hardware, working alongside the community.
What these companies want is to be able to have thier cake without giving back to the community. This is a very slippery slope at the least, and illegal at best, since these sorts of links to binary kernel drivers have been long known to be illegal to distribute alongside the kernel (unless special previsions are made, such as a userland driver).
Also, binary drivers have been known to be buggy and essentially removie the kernel developers from a position where they have control over the kernel as a whole project. I won't even go into the issues associated with a possible security hole in a binary driver, or a binary driver with, for example, spyware in it.
The arguement for it is, of course, that this might mean more drivers. This is a test of our strength as a community. Doing the right thing is harder. It means we won't have all the hardware at all times, and certainly not the newest thing. But we retain control over our computers.
It's hard to say no, but this looks like a clear case where we have to.
Re:Excellent suggestion! (Score:5, Insightful)
Look at nvidias drivers on linux! Always well behind other drivers, and filled with bugs because we have to wait for nvidia to get off thier asses and fix the damn thing.
What happens in 10 years when you're trying to use that binary driver to recover data from an ancient device? If it was an open source driver, you could fix it to work with your system; binary, you're going to have a lot more work to do.
Userspace, anyone? (Score:5, Insightful)
Binary drivers are evil (Score:3, Insightful)
In my opinion, binary drivers are worse than no drivers at all because they release the pressure on the manufacturer. They can say they support Linux which in case of binary drivers is simply not true.
Re:Solves the reason why I gave up Linux (Score:3, Insightful)
Also, for the record, Linux doesn't suck. But I found I could get my command line fix with XP and Cygwin, without the hardware annoyances.
Re:Solves the reason why I gave up Linux (Score:4, Insightful)
You people need to figure out exactly what you want, Linux for the masses (read: grandma, mom, etc) or an O/S where you have to spend valuable time just getting it to work with regular hardware. You bashed the poster for buying "random hardware" and expecting it to work even though you don't know what the hardware in question was, yet in your own message you bought 3 "bleeding edge" Gateway laptops (a fairly well known manufacturer) and you had to (in your words) "_try_ to make it work."
I was going to post this anonymously, but it would of course be modded a troll at that point. Let my karma burn for all I care.
Absolutely (Score:5, Insightful)
One of Linux's biggest problems is the lack of device drivers for common devices, especially newer video cards. Let's face it, companies like ATI and NVIDIA aren't going to release fully open-source drivers. It would be wonderful if they would, but it would also be wonderful if we had flying cars.
Having a stable binary driver interface would make it easier for hardware manufacturers to embrace Linux, give things like wireless chipsets more usability on Linux and drive further adoption of Linux as a viable competitor to more proprietary solutions
The perfect is the enemy of the good, and the more Linux gains a foothold the better it is for open source. Insisting that device manufacturers need to have on-staff kernel hackers in order to keep ahead of a frequently-changing kernel makes it that much harder for manufacturers to support Linux as a viable alternative.
Provided Linux can have a stable binary driver infrastructure that doesn't harm stability, it would greatly help in the adoption of Linux worldwide.
Comment removed (Score:5, Insightful)
Re:Excellent suggestion! (Score:3, Insightful)
Drivers run as kernel-level code.
Closed source code linked into the kernel gets kernel-level privileges. Alone, that is a scary thing.
Worse, binary drivers mean support for only the platforms that vendors choose to support. Users of less popular architectures miss out.
It's much worse than that... (Score:5, Insightful)
No more hacking WRT54G's for you, chump.
Re:Excellent suggestion! (Score:2, Insightful)
That statement is so far off that it occurs to me that perhaps you were being sarcastic. In which case, your moderators should be shot.
Re:Excellent suggestion! (Score:1, Insightful)
How exactly does that help the adoptation of Linux on the desktop? Yeah, I can see concerns about stability, but at least there would BE drivers for half the hardware out there. Do you want a drawing tablet manufacturer in the kernel source just to get a tablet to work with Linux?
Re:No Thanks! (Score:4, Insightful)
The problem is that you will be stuck with the mistakes for the same time.
You can't improve the kernel anymore because you have to keep supporting those mistakes.
You would have to add huge glue layers to your kernels to keep emulating thos mistakes.
It is a bad idea. It has only advantages to those driver writers who want to stay far away from the kernel and want to keep using their crap for a long time. The kernel and the kernel writers are not going to get better from it (they only get extra work supporting lazy driver writers) why should they support it?
Linux development works very easy: do it yourself or convince someone else to do it.
You can convince other people either by motivating them with proper reasoning (and
Nobody has been throwing enough money yet to get the kernel developpers to do it. (And very likely nobody ever will throw enough)
Jeroen
Re:Oh, I'm all for it. (Score:4, Insightful)
The company isn't really interested in fixing any issues with the drivers -- if you have problems with a bug, you have already paid them all the money they are going to get for that particular piece of hardware.
An example: the !@#$%^&* nVidia proprietary X driver. On some older cards, it will cause kernel oopses, within my usage patterns around once per several hours. Is there anything we can do to fix the problem? I'm not a master kernel hacker, but I do have some rudimentary skills there -- I would have at least some chances to make a fix myself; if I wouldn't succeed, reporting a data-loss bug would make us have it fixed by someone with more knowledge in no time.
On my current desktop, switching to text mode the first time X is run after a boot puts the console into 80x25 mode without even doing a TIOCSWINSZ. Somehow, if I kill the X server, reset the video mode then start X again, everything is fine, until the next boot/resume. What can I do to fix this annoyance? Begging to nVidia does nyet work.
Thank goodness for "too much politics" (Score:5, Insightful)
It isn't about "politics". It's about policy and philosophy.
If the hardware doesn't work with Linux, don't buy the hardware/pester the vendor for an open driver, or don't run Linux.
This is the problem (Score:2, Insightful)
And this is why you fail.
-everphilski-
Cut the dogma, there are technical reasons (Score:5, Insightful)
It is not welcome. Linux is about Open Source, and allowing people to link-in binary closed drivers goes against this.
Bypassing the dogma of the above, there are numerous pragmatic reasons why this would be better for linux, even if you don't include support for binary third-party drivers.
Sure, some of these are extreme cases. You can usually get away with just re-compiling the driver, and occasionally, you can even use the binary from the existing version.
The point is you should *always* be able to do this wihtin the same major kernel version. There is no technical reason, aside form the politicis of not wanting to ever allow binary drivers, to not have a stable driver API.
Imagine if the Mozilla plugin API changed with every new version of Firefox. And look at all the complaints when a new Firefox version doesn't work with all the old extentions. It is the exact same.
Ok that's fine BUT... (Score:5, Insightful)
The simple fact of the matter is that most companies are not willing to go open source, for software or drivers. You can argue that's a bad thing, but it is the reality of the situation. So, if open source is out in their book, either because of contractual obligations or mentality or whatever, they are left with two choices:
1) Do Linux drivers, and update them every time the interface changes, which can be as often as every minor kernel revision.
2) Ignore Linux, and let the community write the drivers if they want.
The problem is that Linux is a bit player. They are larger than the other bit players, but they are still tiny, less than 10%. Given that the continous rewrites can get expensive, the choice for many will simply be not to write the driver.
So if you are ok with that, then great, but don't get mad at companies when they won't play by your rules. Are they being unaccomidating? Sure, but so are you.
In the end, it comes down to needing to make a decision of what you want Linux to be. If you want Linux to try and become the next big thing in OSes and start to really make an entrance in the home market, standardisation is needed. Standard APIs, standard UIs, inter-version consistencies, etc. In essence, it needs to become more like OS-X. Now if you are ok with Linux being more of a geek/server OS then that's not necessary, but you can't demand the world change around you.
Define "Stable" (Score:4, Insightful)
Assuming that we had a stable kernel source interface for the kernel, a binary interface would naturally happen too, right? Wrong. Please consider the following facts about the Linux kernel:
But see, the thing is... a "stable" binary interface requires that structures used specify padding, alignment, and fields to be fixed! If these can vary, then by definition , it's not stable. Ditto the variations that depend on kernel build options.
Now, if you want to make the case that it's not possible / practical to make an interface that can cover all of these conditions adequately, well, by all means, do so (though I'd say that the hundreds of existing operating systems with binary interfaces show that this isn't the case in the general sense).
But what I see here is a relatively weak technical argument that is being used to justify an ideological decision.
Re:Excellent suggestion! (Score:4, Insightful)
Sure they will, when they have to so they can remain competitive. Until that time we should support vendors that do provide open source versions of their drivers.
Yeah, I can see concerns about stability, but at least there would BE drivers for half the hardware out there.
Do your really believe that the answer is to trade stability for convenience? As the parent said, we would be right back to where Windows is. As more and more of these type of issues come up I think the Linux kernel developers need to stand resolutely on their principals and provide a quality product even at the sacrifice of some usability. It makes no sense at all to trade long term quality of the kernel for a short term solution to the current driver problem. As for the question of who can be 'in the kernel source', anyone can. Anything that gets included in the official stable branch of the kernel will be reviewed by many memebers of the kernel development team. So far I have had excellent success with the official Linux kernels and don't see any reason this will change if they stick with their current methodologies.
Benefits kernel users how? (Score:4, Insightful)
I am not a Kernel Developer, but I know some. ;) I guess that my open question is how this would benefit kernel users? Yes, I see it would reduce the workload of kernel devs. Yes, I see it would allow driver developers to not have to go through the kernel code vetting process. But, the kernel code vetting process is what is a strong benefit of using Linux, from a user perspective, as I know that the code is well tested by an army of users and developers.
Once you push driver development out of the kernel, yet give access to kernel internals in this way, you introduce a level of uncertainty in so far as stability and robustness is concerned. One must question why these big comapnies are pushing for this, but most human kernel devs are not.
Re:Oh, I'm all for it. (Score:3, Insightful)
I do wish that linux and MacOS X has similar setups, but it is difficult to setup such a system without having a central authority with a great deal of power (to abuse).
Binary Drivers = Maint. Nightmare + Security Woes (Score:3, Insightful)
GKH raises good points about how a stable binary driver interface will open the floodgates to both security problems and to update/maintenance problems. As it stands right now, Linux kernel developers can quickly respond to threats because they are able to fix all instances of a given problem, in all drivers, at the same time. If they do not maintain this flexibility, either some drivers stop working unexpectedly when security fixes are made and the interfaces are forced to change (making Linux appear "unstable") or backwards compatibility must be maintained making the Linux kernel grow over time (whenever a new interface has to be written to address flaws in the old interface).
Yes, abstraction is good...but, in this case, stability, the perception of the user and maintainability (where the *real* costs lie) must win over abstraction. Most of the kernel developers are not being compensated; how often do you think that backwards compatibility is going to be maintained? Its not. Right now, fixes are accomplished because it is easy to accomplish - global search and replace, etc. Make it difficult and it just won't be done.
Manufacturers want binary drivers because they want to play for free - they want all of the benefits of open source without any of the costs. Not cool.
Re:No Thanks! (Score:5, Insightful)
Because of this, I'm 100% not convinced making binary driver developers lives harder changes anything. Are large businesses (the type who make hardware that's difficult to reverse engineer) likely to say, hey, gosh, you know this Greg KH guy kind of doesn't like closed drivers, maybe we should open them up to please him? Nope. They'll just work around the difficulties or not provide drivers at all.
I've been a Wine developer for years and have spent many hours doing this impossible thing of which you speak, and your average copy of MS Word or Steam is a LOT larger than your average driver. Yes, it's hard. No, it's not impossible. I've heard various excuses as to why kernel development is just different!! to userland software development, and don't buy it. Yes, having to reboot when a crash occurs is a royal pain in the ass, but so is not being able to get a backtrace because the game you're investigating treats any attempt at attaching a debugger as an attempt to hax0r its copy protection. Different space, different challenges. It's still possible.
Re:Excellent suggestion! (Score:5, Insightful)
Just to play the devil's advocate - yes. That is, if you want the average Joe Blow to start even thinking about Linux instead of Windows.
Windows is ubiquitous. OSX has mind share at least in part because almost every peripheral you purchase and plug in just sorta works. Linux has hundreds of thousands of forum posts dedicated to getting standard pieces of hardware - like mainstream video cards - working in the OS.
So in theory, yeah - I'm for allowing closed source drivers to be developed for linux, because without hardware support, you'll have very little non-tech usership of linux.
Just my opinion, of course...
Does time change the debate? (Score:4, Insightful)
I agree that when the Linux kernel was young and untried, standardizing a binary API was bound to become a millstone in a short period of time, as the kernel internals were in a constant state of churn and iterative improvement. Nowadays though, surely, the kernel has been "shaken down" enough that it could afford to commit to binary APIs that are stable at least throughout each minor version number?
Returning to ideology, I can see how a stable binary API would be useful even to open source hardware. How much easier is it, to say "drop this file under
In itself, that says nothing, either pro or anti, about the availability of driver source.
Re:Oh, I'm all for it. (Score:3, Insightful)
I never had significant problems with certified drivers, but I guess that some of you know good examples.
Hardware vendors (Score:2, Insightful)
Linux is at a really important part in its evolution. Caving in to closed source interests would be counter productive in the long term. It is better to force/cajole the vendors to finally "see the light" with open source and the GPL. Maybe eventually another graphics card vendor will appear and become the champion, precisely from having open source drivers. The manufacture of electronics in Asia in particular is exploding, where there is a market, a vendor will appear. Patience.
Re:Only one word (Score:5, Insightful)
the question I have for this is "why?" wouldn't a stable binary API likely result in far more third party hardware support for linux? possibly more laptops that are actually compatible with linux?
This seems like a case of open source programmers shooting themselves in the foot because they want everything to be open source... not every application and driver is going to be made open source just to suit the desires of the linux development community. It seems to me that sticking to a hard party line against closed source software instead of trying to co-exist with said software is bound to keep linux in relative obscurity and pretty much ensure that it never becomes a viable competitor in the desktop market.
Re:GO FOR IT (Score:2, Insightful)
out of touch linux kernel 'hackers' (Score:3, Insightful)
That said, this whole discussion is as silly as the one about not putting a kernel debugger in the main kernel source code. Frankly, linux desperatly needs both a kernel debugger, and an ABI to be a REAL alternative for many customers. It also needs the ABI for driver developers so that we can write a single driver and expect it to work on the dozens of flavors of linux we are expected to support. Saying that everyone should opensource their drivers is like saying food should be free. It isn't going to to happen and wishing for it, won't make it happen any sooner. In the interm, almost all the hardware out there has better support on windows (Our sysadmin can't even get support for major linux distributions, from major hardware vendors, even when they have little linux logos on their hardware and websites) the windows drivers tend, to accually work, and they almost always have better features sets. This isn't going to change as long as the "opensource" community treats hardware vendors that think they have IP in the driver as second class citizens.
Oh, and for people who don't accually work for hardware companies that ship drivers, driver development is often times an expensive process, not because the software engineers are expensive, but because the hardware and software needs to be tested and certified in particular enviroments. There are orders of magnitude more linux distributions this makes it cost orders of magnitude more to test and support than a half dozen windows enviroments, most of which can be tested at microsoft, or one of the major OEM's if the hardware isn't avialable onsite. Putting 10x the money into a market that may be less than 1/10 of sales is not always a good idea, especially when resources are limited. Creating an proper ABI helps to solve this problem.
That said, if the damn linux kernel accually had a real architecture, it could support an ABI, and even isolate itself from rogue drivers. As it is, the kernel arch is pretty much non existant and just a pile of code that tends to behave like a real kernel, except when you try to do something a little outside of the mainstream desktop or small web server enviroment. This was fine when the whole kernel was just a few hundred thousand lines, but given its current size its getting massivly unmaintainable. This is proven by the fact that linux system stability seems to have gotten really bad over the last few years. Getting to a stable system, takes a lot of vendor testing by the likes of Suse, Redhat, etc.
Lastly, the tainted concept works fine for the kernel developers, why not carry it forwared so that any binary driver simply marks the kernel as having a binary module loaded, and uses the standard abstract interfaces instead of linking against all kinds of unneeded kernel crap that just provides the posibility to screw something up.
necessary for the desktop (Score:3, Insightful)
Here's a sample of what I put up with. I downloaded Agnula Demudi 1.2.1 and installed it with the 2.6 kernel. I was ready to install some Nvidia drivers. But after some searching, I couldn't find any binary driver interfaces compatible with my kernel. Fine, I can compile my own. So I download the interface sources and launch module-assistant. It complains that riva driver support in my kernel conflicts with the nvidia driver, and I need to recompile the kernel. (I then went through the joy of trying to find the hidden demudi sources and figuring out how to patche them and configure them, ultimately failing to compile it, but this is getting away from the topic.) Finally, I said screw it.
You might blame the distro, but it's really the kernel at fault here. Recompiling the kernel to support a driver is NOT something that a user should have to do. Windows does not require you to recompile your kernel to install drivers.
I would rather have drivers than fanaticism (Score:3, Insightful)
As long as Linux kernel developers complain that binary-only drivers are "illegal", Linux will have less hardware support. One of the major complaints people have against Linux is that a lot of devices that one can attach to a Windows machine plain simply do not work in Linux (I still think Linux is far behind Windows when it comes to wireless drivers, for example). I want to see a true alternative to Windows on the desktop; GPL fanaticism and an inability to understnad how big corporations work harms this.
Re:As the article says, it's illegal, and a bad id (Score:3, Insightful)
The bottom line is that having code be open is only important to a fraction of *developers*, and an extremely small small fraction of the general populance. Ultimately, "Free" software people want to push their ideoligy on others, they don't care about makeing functional easy to use systems.
So preach all you want. Very few people care.
Re:Only one word (Score:3, Insightful)
I thought that Linus usually put technical correctness above political correctness, but it looks like I was wrong.
Re:Excellent suggestion! (Score:5, Insightful)
Many drivers suffer quality issues or are just abandoned because drivers must be changed to work with each new kernel. That is time that could be spent stabilizing them, improving them, or writing new drivers. It is probably the single biggest hurdle to getting a broad range of driver support for Linux.
For some drivers we already do have an API. For example, sound cards can use ALSA instead of coding directly to the kernel. Driver quality and quantity improved significantly because of ALSA. The same thing goes with SANE. The only problem there is that SCSI and USB support has been lagging.
Re:Absolutely (Score:2, Insightful)
Insisting that device manufacturers need to have on-staff kernel hackers in order to keep ahead of a frequently-changing kernel makes it that much harder for manufacturers to support Linux as a viable alternative.
No one is suggesting that companies shoulder the additional burden of constantly updating their drivers - that is taken care of for them automatically once they submit the driver to mainline. This is only an issue if the manufacturer refuses to do so, e.g. for a binary driver, or for separately maintained source. The former is considered unacceptable by most kernel developers, and the latter doesn't seem to have any benefit to the company.
The only people who should be clamoring for a stable source-level API are the kernel developers themselves, since they're burdened with the work of updating drivers when an interface changes.
Re:Excellent suggestion! (Score:4, Insightful)
With respect, I think there's more than one question to be considered there:
As I see it:
And after all, this is a deal that will be easier to revisit in the future than it will be to revoke once granted. The pressure to allow binary submissions will continue for as long as Linux as a noticable commercial deploymen. The kernel devs can afford to wait and see here. I expect that's just what they'll do.
Re:Excellent suggestion! (Score:5, Insightful)
No, no, no, no NO. We don't want hardware vendors to write drivers. Besides, most hardware vendors don't want to maintain drivers for Windows, MacOS, FreeBSD, NetBSD, OpenBSD, BeOS, HURD, Xen, Linux, Solaris, and each of the incompatible versions of each of them, as well as any new platforms that arise. Even if they do, whether or not they can write good quality, full-featured, secure drivers for all of these platforms is an open question.
All a vendor needs to do is to make good, solid interface documentation, and make it available without NDAs and other childish restrictions, and the drivers will not only be written, but they'll probably be shipped with the operating systems, and for the most part, just work.
Companies that specialize in PC hardware should stick to the hardware, and let the software specialists write the software.
Re:This is the problem (Score:3, Insightful)
Re:Hell, no! (Score:3, Insightful)
Oh, wait, it's been done. He didn't listen.
Re:As the article says, it's illegal, and a bad id (Score:5, Insightful)
But why not try our best to have as much control as we can?
Re:Solves the reason why I gave up Linux (Score:2, Insightful)
Wait, we're lambasting slashdot "groupthink" here, though. My bad. I should say "You only like Linux because you hate Microsoft. You hatey hater man. Stop hating because you're jealous"
Re:Excellent suggestion! (Score:5, Insightful)
Uh, yes. Because everybody knows that being open source is a magical recipe for never having any bugs.
Writing video drivers is hard dude, and nVidia employ several experienced people who do it full time. I've seen them discuss technical issues in public before and have no doubt in my mind that they are experts.
Given how many open source drivers are buggy as hell (i810 audio, hello) there must be another explanation. Here's one try.
I hypothesise that what determines the quality of a driver is the number and quality of developers working on them. Closed source drivers sometimes suffer because the quality and/or quantity of developers writing those drivers isn't good enough. Being open source means that theoretically the quantity and quality of developers is unbounded. However, note that this is theory - being open doesn't actually imply that you will suddenly get legions of experts in video hardware writing your drivers for you. It merely makes it possible.
To be honest, I have serious doubts that we'd have such good drivers if nVidia GPLd them tomorrow and simultaneously fired all of their Linux developers. Being closed doesn't mean you can't have good people working on it, and being open doesn't mean you will. It simply alters the bounds of the possible.
Re:This is the problem (Score:5, Insightful)
It's funny how you warp things around.
Re:No (Score:3, Insightful)
It seems unlikely at this point that Nvidia will ever open-source their video card drivers. (They might not even be able to legally - it's not uncommon for commercial software to contain code from third parties.) Assuming that this is the case, a stable ABI would make Nvidia's task much easier and would probably result in higher quality Linux drivers.
Nvidia is no exception to this. Several recent Nvidia driver releases have not worked at all on my GeForce4. When that happens, it is nice to have the option of switching to an earlier driver release. Unfortunately, the way things are now, that may mean installing an earlier kernel as well. About a year ago, "installing" a somewhat older Nvidia driver entailed downloading kernel source so the installer would have something to compile its Linux-to-binary-Nvidia-module interface layer against, then applying a patch to Nvidia's source code to fix some bug, then fixing the Linux kernel source to add an EXPORT_SYMBOL statement that someone had taken out (breaking source compatibility during the middle of a stable kernel series). After recompiling everything, it worked, but it took me several days to figure it out. Most users would have given up.
This is the sort of thing that drives users away from Linux. I would like to live in a world where all the best hardware was fully supported by open source drivers, but it isn't going to happen any time soon. The current model, in which closed source drivers are tolerated but deliberately rendered difficult to support and maintain, doesn't work very well. It would probably be better in the long run to either disallow binary-only modules (and give up on accellerated opengl on most graphics cards, among other things) or to accept them and at least make a basic effort not to break things.
Learn to read. (Score:5, Insightful)
Re:Excellent suggestion! (Score:4, Insightful)
Currently it is almost impossible for hardware vendors can provide a binary driver. It must be adapted to every distro and kernel rev. For the most part they don't bother.
Instead, we get reverse-"engineered" (i.e. hacked-together) drivers made by people doing their best to get devices working with no real understanding of how the device works. And you think that promotes stability, performance, and security?
Ideally, we'd have quality open-source drivers for everything. Since that hasn't happened, now what?
Re:Excellent suggestion! (Score:5, Insightful)
You're ignoring a LOT of the praticalities of the matter. Many driver manufactuers can't provide OSS drivers or the necessary info because:
1) It's against the law to provide methods for tampering with the equipment. (e.g. Wifi cards.)
2) Much of the code and/or hardware design is licensed from other parties, and they can't get permission to open it.
3) The ever important Time to Market consideration would be quashed if manufacturers had to wait for the driver to enter the tree then get distributed to the major Linux distros before releasing their hardware.
Besides, most hardware vendors don't want to maintain drivers for Windows, MacOS, FreeBSD, NetBSD, OpenBSD, BeOS, HURD, Xen, Linux, Solaris, and each of the incompatible versions of each of them, as well as any new platforms that arise.
That's why hardware manufacturers would like to see specifications like UDI [wikipedia.org] and NDIS [wikipedia.org] followed. Unfortunately, those wonderful software people who are apparently so much better at this stuff have decided that they don't need anything as passe as a cross-platform driver API. Mr. Stallman is leading the charge on this one. Personally, I think he's stuck on stupid [thepoliticalteen.net], but that's just me.
Here's my personal feelings on this. In the short term driver code has value to manufacturers for whatever IP it may contain. In the long term, driver code has precisely zero value to the OSS community. All they do is allow for more old cruft to hang around. I also think that supporting a cross-platform driver would make everyone's lives easier as Windows, Linux, FreeBSD, and whoever else can simply use the same drivers. Such a world would be a hardware Utopia in comparison to the driver issues we have today.
Re:Ugh no (Score:2, Insightful)
It is just that once you open the gates, they won't ever be closed again.
This is why I don't write device drivers for Linux (Score:4, Insightful)
Well, congratulations. You have your religous purity. And guess what- it's comming at a cost. You wonder why Linux isn't more popular on the desktop? Well, here's part of the reason. It's hardware support will always- ALWAYS- be behind that of Windows. Why? Because when the hardware ships, it ships with Windows drivers that the hardware vendor wrote with it. Note that Windows pulls the same sort of API changing crap that Linux does. The difference is that the hardware vendors look at Windows, and the half man-year per year cost of supporting Windows costs, and go "but we have to support Windows if we want to sell more than 3 units." They then look at Linux, and the half man-year per year cost of support Linux, and go "Supporting Linux is not cost-effective at this time." I know, because I've seen this happen. So now the hardware is out there. And now we wait, for someone willing to step up and volunteer the time to write, and maintain indefinately, the driver. Someone less capable of doing it than the hardware manufacturer (this isn't to question the capabilities of the current kernel developers, but the fact of the matter is that there is a huge advantage to being three cubes down from the hardware developers, and capable of wandering over and asking direct questions, instead of having to reverse engineer what is really going on, having worked both ways).
So this is the fundamental question: which is worse. Having binary-only proprietary drivers, or being forever behind in hardware support and not having people contribute simply because they don't feel like having to constantly update the driver once they finish it, they'd like to be able to move on. I come down on one side, Linus and the kernel developers down on the other.
Fine. Their kernel. Their problem.
Linus' words, now for real (Score:5, Insightful)
- Linus Torvalds on linux-kernel
And many people forgets that non-gpl drivers may be very well impossible to write at all (at least some lawyers think this), drivers are not at all like an app is WRT to gtk, drivers are more like "plugins". Plus, a closed driver module makes MUCH HARDER to debug bugs if the driver is doing bad things, and you can't know that (which makes harder to stabilize and/or develop the kernel. Several closed drivers can make it a hell or impossible at all.
Re: PLEASE give us a stable driver interface! (Score:2, Insightful)
So I wrote a nice driver for it, with help from the excellent Rubini book since there's no frickin' driver documentation and the Linux sources are uncommented (putting your name at the top doesn't count as commenting on any team I've been on). It worked for a few months, until the next incompatible change in the kernel. Then I poked around in the kernel until I thought I'd figured out what had changed. Got it kind-of working (DMA is unreliable and I don't know why). Then the 2nd edition of the Rubini book came out, so I rewrote the driver and got it semi-OK again. For a few months.
The kernel has had about a zillion incompatible changes in the driver interface since then, ALL UNDOCUMENTED, there's no 3rd edition of Rubini's book to sort it out for me, and I'm just lost digging through the kernel sources. It's always the same pattern: customer complains, I spend a few days fixing it, and it sort-of works for a few months until the next gratuitous interface change.
OK so I'm a for-profit vendor and therefore deserve to die (how dare I want to be paid for being a programmer, it's only people who don't create new IP who should be allowed to choose what they do for a living). But I'm not the vendor. I wrote the driver for their device (and plenty of other open source stuff) because it needed writing and no one else was doing it. The driver is distributed as fully commented source (obviously), and I've given it out to anyone who asked for it (uhh ... both of them -- this hasn't made me a nickel in extra sales for the package itself, I tell users who want reliable Q-bus interfacing to use my DOS version because there's no OS to break my driver there, it's worked unchanged for YEARS). The users haven't touched a single line of code on their own that I know of, all they do is complain to me. So what's wrong with this picture? Why isn't Open Source magically making everything work, at no cost to anyone?
It's just plain arrogant to assume that Groovy Open Source will always fix itself, and therefore it's OK to make the kernel interface be a rapidly moving target with no real manual. I'm sure that when we're talking about some extremely commonplace device that hundreds of thousands of people have, it's not hard at all to raise a posse and go after new bugs when the kernel changes. But this device I'm talking about costs $2575 a pop and is of no interest to anyone who isn't keeping a 30-year-old minicomputer system alive with a brain transplant. Absolutely no one is helping me maintain the driver even though they have everything they need to do it. I'm doing a lousy job of maintaining it because it's 0.0001% of my job description, and it's just not my strength (I know how to program bare metal, keeping up with Linux internals would have to be its own full-time job).
I couldn't care less whether drivers are required by law to be open source (although I really can't believe that's enforcible on a loadable driver, licenses exist to make exceptions to the default copyright restrictions, and interoperation is not copying). If people want to see my I/O code they're welcome to it. Just please stop making it break!!! Especially if you're not going to bother helping me maintain it. I've got my hands full just keeping the user-mode code working (WTF happened to /dev/vcsa7 and up?! and /proc/meminfo?!).
Anyway my point is, if Linux would pick one driver interface, and commit to supporting it (OK, possibly among other
Re:of course it should (Score:3, Insightful)
The real problem is this need to have unique drivers for every instance of hardware. Part of that problem is that manufacturers keep wanting to put their code in the host system for various reason. One common reason is to use the host CPU for work they are too cheap to do in the device they are selling. And another that has come out is their desire to access the host system itself (and something in the kernel involves a huge amount of access).
This practice is bad because it compromises the integrity, reliability, performance, and security of host systems.
What is really needed is a standard way of accessing hardware devices so there is no need to have unique drivers for each device. And for many devices, such as disk drives, that already exists. This just needs to be extended so that it works for all general and common devices. The only time a new device should need its own driver is when it is so uniquely new, that there is no analogy to what it does in existing devices (e.g. it would also need a new device file name in the /dev directory as well).
Re:This is why I don't write device drivers for Li (Score:3, Insightful)
Re:necessary for the desktop (Score:3, Insightful)
> a driver for Linux.
Boo fucking hoo. I'll take my money elsewhere...
Re:Excellent suggestion! (Score:2, Insightful)
0
Problem comes up in Linux, go to google, search 5 million forums, eventually find some obscure fix from a real programmer, rinse, repeat.
No ABI no fun! (Score:2, Insightful)
1) Experimental driver stage. I distributed the source and had online instructions, but you would be surprised at the large number of people that I had to walk through compiling their kernel with the correct
2) Late experimental stage. I had all the problems of the previous stage, but now the kernel API was changing under me so I had to put #ifdefs in to deal with it. I figured the problem would go away once I was integrated with kernel source.
3) In the kernel. Yeah I made it into the kernel. Okay first it was the pcmcia package and then the kernel. But now I had to strip out all the #ifdefs because we don't want that cruft in the kernel, but I still had to maintain the #ifdefs for other kernels. So now I had all the previous problems, but now I had to make patches with and without the #ifdefs. I figured the problem would go aways once everyone moved to the new kernel.
4) Firmware changes. Oh no! Cisco changed the firmware which changed a bit the I/O interface. Oh and look they are still changing the API in the kernel. So I can patch the new kernel code to support the new firmware, but I can't expect everyone to upgrade kernel just for my driver. (I wouldn't even do that because the XXXX driver doesn't work so well in the latest kernel.) Now I have even more problems to deal with including everything from before.
5) Throwing in the towel. It became just too much of a time sink. Both sides of my driver was changing like mad (the hardware and the kernel API) and the poor users that were trying to make it all work with kernels that they wanted to use. All my time was being sucked up in maintaining the status quo and I couldn't work on anything new, so I turn the driver over to good hands and moved on.
Now imagine how nice would be if in the experimental phase I could release the source and a binary for everyone to use. I wouldn't have to tweak and recompile for every new kernel. Anyone would be able to just grab the binary and use it if they wanted to. (Kinda like Windows... Ironically I use ndiswrapper for my new laptop with a broadcom driver and it rocks! I've used the same windows driver in linux for the past year across many versions of the kernel. It sucks that the windows network driver ABI is the only driver ABI that linux has.) If the firmware changed, I or anyone else could fix it and everyone could use it.
Whether or not we Linux allows closed source drivers is orthogonal to an ABI. Technically you can write closed source drivers now and if you want to, you can prohibit closed source drivers with your new ABI.
Re:Excellent suggestion! (Score:3, Insightful)
No, try again. The whole driver issue is one of the wiser things that Microsoft ever did. Back in the day hardware manufacturers made hardware, and software providers were expected to purchase the specs and implement their own drivers. Microsoft (despite being a fairly large company) realized that there was no way they could keep ahead of the driver game, so they used their clout in the PC industry to force (yes, force) hardware manufacturers to write drivers for their Windows Operating System.
Microsoft wasn't stupid. They realized that there are serious advantages to distributing the development among companies other than themselves. Sadly, the Linux developers haven't wrapped their heads around this concept yet.
Re:Solves the reason why I gave up Linux (Score:2, Insightful)
It's funny how the masses always complain about windows being instable and crashing. I have news for you, windows does not (not XP, anyway). All the crashes I've seen in the past years were cause of crappy drivers (mainly nVidia and Ati). That's because Microsoft developers are stupid and can't develop a decent driver API? (because we all know that the average IQ in microsoft is something around 15, and that the legend of the 1000 typing monkeys... ok, but I ain't bein funny)
I'm perfectly aware of the reasons mentioned in the previous posts. But the decision isn't trivial. There is a compromise/tradeoff to make, and it ain't so simple. Is it worth to attract the masses? I doubt. the real deal for the masses is Apple... masses, in the IT world, don't need to be "free to do things". Because that translates in "free to damage things". So the real deal is a vendor that offers you everything from its own factory, all shipped up in a cool package, with just 4 models to choose from (ok, maybe even 20, doesn't make much difference). You run your thing, you don't need to know nothing, and IT'S FUCKING BETTER YOU DON'T. Everything works, as long as your needs conforms to the standard needs. I'm sure that 99% of the people would be damned happy with this. And to them I say, go Apple.
For me, this is just a cool version of the Soviet Republic. But I'm a mad anarchist, so just leave me alone with my crappy Linux, that needs days to be configured with mainstream hardware, but that does not "limit" me in any way
(Many would say mine is just a bunch of politic arg... idiocies. True. Because Linux and Open Source is a political matter. Being opensource does not give a project any mere technical advantage over a closed source one. It has its upsides in how the software interacts with the community of users/developers, and hence is a social/politic matter)
Re:Excellent suggestion! (Score:1, Insightful)
So be it. I don't care if every 3rd grader can't run Linux. I want it because it works. And always works. Dumbing down the kernel to allow for a binary only driver to be released by a manufacturer and then forgotten is useless to me.
I understand that (insert your favoite vendor here) needs to make cash, but why not allow for proper driver development? I make sure the device I'm using has wide support no matter what OS I'm using. how can that be a bad thing to the hardware folks?
Re:Excellent suggestion! (Score:3, Insightful)
BTW, those are simply components. Consumer hardware is a complex collection of all those parts, usually containing its own set of interfaces and design features. Not to mention all the hardware that uses custom ASIC chips (pretty much everything), FPGAs (common alternative to an ASIC), and complex software drivers (e.g. Video cards, Wifi, Modems, etc.) that contain all the logic necessary to actually use the hardware for the intended purpose.
Basically, what you're saying is "here's a video card that uses brand XYZ Digital YUV to Analog DVI coverter chip, go write a driver for it." Everyone else just sort of looks at you with their mouths hanging open as thoughts of frame buffers, multi-pipelined 3D texturing units, video overlays, Video ROM code, and other complex features float through their heads.
Re:Absolutely (Score:3, Insightful)
They have on-staff kernel hackers right now. (Unless those ATI and NVidia binary drivers I keep hearing about are written by the Linux Kernel Fairy.)
Merging their code with the mainline linux kernel should allow them to share their maintenance burden, not increase it....
Re:out of touch linux kernel 'hackers' (Score:3, Insightful)
Actually, no, saying that everyone should opensource their drivers is like saying that recipes should be free (as in speech).
We're not expecting vendors to give away their hardware, we just want them to give away the interface to that hardware. Does that open things up for reverse engineering? Possibly, but a reverse-engineered video card probably isn't going to perform as well as the original. It'd definitely be better for the card manufacturer in the long term (which means we need to convince manufacturers that long-term thinking is good), since they would have less load on them for software development, and it'd be better for the Linux community, because we have the hardware specs straight from the horse's mouth, which means we can operate the hardware exactly as the manufacturer intended.
Yes, changing to an open-source model for drivers is a big step, and will cost manufacturers in the short-term, but the long-term benefits are worth it.
Re:No Thanks! (Score:3, Insightful)
Some rebuttals:
1) A lot of the work involved in maintaining a driver is keeping up with in-kernel API changes. If the driver is in the tree, the kernel developers will handle these sorts of sweeping changes, and the hardware vendor doesn't need to worry about them. Also, the kernel developers are pretty easy-going about driver coding style, as it tends to be isolated.
2) If you can't see the code for the module, you don't know what the module did. If you load the module, and it tramples some memory, and you unload the module, that memory is still corrupt. This is why loading a module taints the kernel, even after the module is unloaded. It's impossible for the kernel community at large to debug kernels which have had closed-source modules loaded.
3) Getting the end-user to build and install a kernel module is not hard. Vmware manages to make it an automated part of the installation script. The advantage of shipping source to end-users is that those who are knowledgable will be able to make your module work on other kernel versions, while a binary version is by definition limited in terms of compatibility.
Re:Only one word (Score:5, Insightful)
In other words, it would turn Linux into the same kind of piece of shit that Windows is, and defeat the entire purpose of using it!
Re:Excellent suggestion! (Score:3, Insightful)
Good luck on those video games, then.
or find ways to force it to work when we do (ndiswrapper or reverse engineering).
I really should be snickering like an idiot at this. Really. Read the first four letters of the driver name you just gave. Now think long and hard about how much trouble could have been saved if Linux had just supported binary NDIS drivers in the first place.
Re:Binary drivers are evil (Score:1, Insightful)
Meanwhile back in the real world Debian ships on eleven architectures, some of which these manufacturers have probably never heard of. Goodness knows how many more the kernel itself can run on. Life out on the fringes is interesting enough, without a return to the nightmare of proprietary software.
Few closed source products come anywhere close to this level of portability, and a closed source driver means supporting only what that vendor is prepared to support, versus supporting all of them where someone is prepared to make the porting effort (or accidentally makes it whilst doing another port).
Stable APIs for these things are very desirable, I shall write to Linus and tell him to stop changing them for no reason at all.
LHQL / Driver development costs (Score:4, Insightful)
Initial costs associated with a manufacturer-supported driver:
Ongoing costs associated with a manufacturer-supported driver:
These costs exist even if a version of the driver is merged into the mainline kernel. The only problem solved by such source-level merging is compatibility with the latest kernel version. It is not acceptable to the manufacturers' customers to be required to update to the latest kernel/distribution to be able to use the device.
Here's the key point: If there is no binary interface between the driver and the kernel, all of the above costs skyrocket. You have M kernel versions against N distributions, with the total increasing over the life of the product. If there is a binary interface guarantee from the kernel development team to change only very slowly and only extremely rarely breaking compatibility -- like the guarantee Windows provides -- then the incremental costs are containable. It is reasonable to expect that 95% of their testing on 2.6.5 is valid on 2.6.14.
The perfectly reasonable response from kernel developers is that with closed-source drivers they get stuck debugging problems that are't kernel-related (I don't hold ideology to be economically significant so I'll ignore it here, without insult to people's strong opinions on the subject). Their proposed solution is to require the driver's source before they'll help with the debugging.
From the manufacturers' point of view that's a very draconian requirement. They are justifiably concerned about intellectual property (availability of the source makes it much easier for competitors to reverse-engineer the hardware/firmware). Surely there must be a middle ground. Is there some way to have a relationship between the device manufacturers and the kernel developers that minimizes everyone's costs?
I think there is. Note that all of the above costs and issues are just as valid in the Windows world as in the Linux world. Microsoft doesn't want to deal with bad drivers crashing their systems, costing them both development/debugging time and reduced perceived stability (--> lower sales). Their solution is the Windows Hardware Quality Lab (WHQL).
The WHQL is a separate entity from Microsoft. Device manufacturers are required to submit their driver source (effectively under NDA) along with their device. The WHQL staff runs the driver through a battery of tests, probably mostly automated. If the device and driver meet stability standards set by Microsoft, the driver is signed by WHQL. Windows checks for this signature at installation time and warns the administrator if it is not present. Microsoft can reasonably refuse to support non-WHQL-signed drivers when crashes occur, for exactly the same reasons that Linux kernel developers refuse to support drivers without the source. This system has been the single most important factor in Windows' significan
Re:and people defrauds it (Score:2, Insightful)
http://www.microsoft.com/whdc/whql/resources/spec
E.g for one of a real time virus checkers that layer over filesystem, they test things obscure filesystem features like defragmentation support, and oplocks and reparse points. Plus there is a 14 day stress test. And they update the test to catch common bugs. Of course a decent company will do this sort of thing, but in practice most companies will release undertested code if they are under pressure.
So the HQL certification means that you run these tests. Then you fix the test failures and submit the log and binary to Microsoft and they sign the binary.
It's not perfect - as the Raymond Chen post says, but it's a lot better than nothing. But the cool thing is it doesn't really need to be perfect, if the drivers are visibly unstable, people will stop buying the hardware and the company will go bust. Both NVidia and ATI hardware is rock solid with the latest drivers, so who cares if they cheat a bit with 3dmark and HQL.
Re:Untrusted computing (Score:3, Insightful)
Re:GO FOR IT (Score:3, Insightful)
When the source code is available for modification, *everyone* benefits, whether they're reading it, hacking it, or just using precompiled binaries. When I need something new in software, I may not be able to code it myself, but I can put it in bugzilla, where others in the community can discuss it, assign it, and eventually implement it.
Of course the process is not perfect. It is a human process. That is part of its appeal -- the community supports its own software, rather than relying on a company to pump out binaries... who may not be around next week.
There is nothing elitist about saying that I am perfectly satisfied with what Linux provides, and there is nothing wrong with valuing the freedom that its open nature gives to all users -- remember, those freedoms benefit them whether they read the code or not.
From this user's point of view, the extra freedom, stability, and community that Linux provides are well worth the wide selection of ordinary hardware -- at ordinary prices -- that I choose to run it on. For me, the value of an operating system is that it provides a platform which offers freedom to me and to my community while we do our work. Putting off-brand generic wireless cards with quick-hacked binary-only drivers into a system does not help me do my work -- even on "supported" systems, that has usually just given me a headache and required a trip back to the shop -- and it would probably force some compromises in the freedom we value.
For you, it seems that an operating system is nothing more than a collection of software to be used unmodified and unexamined, while you do other tasks, without the need for a community to support you if you need to change it. Those needs are perfecly valid, and perfectly incompatible with the Free Software movement. I would be happy to help you select and purchase such a system from one of the many vendors who will sell it to you. You'll be able to plug cheap hardware with crashy drivers into it 'til your heart's content. For support, you'll be able to call the company, whom you'll soon find have invested even less in support than they did in the cheap hardware.
And if your needs should change, our community will still be here, and we'll be glad to help you find a system that meets them.
Re:Only one word (Score:1, Insightful)
Unless the DRI people [freedesktop.org] are lying to me, no, that's not what DRI is. DRI is "framework for allowing direct access to graphics hardware under the X Window System". (And DRM is the "kernel module that gives direct hardware access".) Hmm, nothing about 3d support there -- just opening it up so user apps can play with the hardware directly.
Yes, it "integrates with Mesa, an open source implementation of the OpenGL API". That does not make it "3d support inside the kernel".
If you had a kernel module that allowed user programs direct access to your sound card, and could write a userspace program that implemented 3d audio for your particular sound card, would you claim that the kernel had "3d audio support inside the kernel"? This seems a truly bizarre definition. By this logic, the kernel has "support" for *everything* "inside the kernel": just su root and twiddle with
Re:This is why I don't write device drivers for Li (Score:3, Insightful)
No, they don't, unless you are putting Windows XP and Windows 95 in the same category. Just about any Windows 2000 driver will work on any version through service pack 4, but with Linux I need to recompile my drivers whenever a minor version number changes. Joy.
We should all be supporting Project UDI. (summary) (Score:3, Insightful)
See the long version [slashdot.org] of this post for expanded discussion of these points...
[By the way -- AKAImBatman, please send me some email, I'd like to chat with you further about Project UDI...]
Re:*I* have an idea! (Score:1, Insightful)
Just because they used the VM layer from mach doesn't make it a microkernel. Though at least the graphics driver runs mostly in userspace (much just like X11 on UNIX, in fact).
Oddly enough, NT4 is still considered a microkernel by some, despite having GDI, all drivers and all filesystems in kernel. Linux+X11 is more of a microkernel than NT4!