OSNews

On all of these *nix systems, the majority of the driver support lives in userspace and interacts with the driver interface in the X server, which is under a non-copyleft, non-share-alike license. The part that involves the kernel is the direct rendering code, which interacts with the DRI framework. To get around the linking problem with the Linux kernel, this part of the nVidia driver lives in userspace and talks to a GPL shim layer that they load into the kernel. If the DRI changes, they only need to update their shim.

FreeBSD and Solaris face challenges because Linux DRI is advancing beyond their capabilities, mainly due to contributions from Intel. FreeBSD and especially Solaris are mostly locked into the frameworks they have. This is the double-edged sword of stable interfaces. As nVidia works to keep their shim in sync with Linux DRI, it becomes a hassle to continue to support these other kernels.

In his "infinite wisdom," Linus decided that eventually people's patience with--and trust in--proprietary drivers will run out, making stable in-kernel interfaces a non-issue. The Linux kernel development model works great for OSS drivers, and most hardware will eventually be supported by OSS drivers. Our suffering is temporary and for a good reason.

Pardon - you do realise that DRI exists in both Solaris and FreeBSD; Solaris has the Intel driver merged, the DRI merged and Mesa is included with Solaris as well.

There is no double edge to a stable interface - what it does mean is this; when you design an interface, it'll take longer - rather than throwing ideas at a wall and see what sticks, it'll require going away, designing, arguing, debating, analysing then implementing - sure, it'll take longer, but what it means is that the API has been properly thought out before being merged - and better still modular enough so that new features can be added without breaking compatibility.

A prime example of this would be Solaris's new network driver API which covers all the facits of networking, and when features are added, such as WPA support, all wireless drivers support it by virtue of it being in the actual driver API rather than it being an after thought.

I don't want to bash Linux, but to me, it always seems that people just keep throwing ideas and see what sticks rather than sitting down and logically thinking out what the requirements of the API are and all the various issues that surround it.

"Sure they are a pain in the ass on Linux - but for that you need to blame Linus for his infinite wisdom about no stable kernel APIs."

A stable in-kernel API does nothing but hinder further development in terms of new features and bugfixes. Please read Grek KH's response on this for more info, called "stable_kernel_nonsense.txt" in the kernel source's Documentation directory. (It's also available online at his site: http://www.kroah.com/log/linux/stable_api_nonsense.html )

(Sorry, I meant to vote you down but clicked the wrong button. Would someone do so for me please? )

Last time I checked, you weren't supposed to mod people down just because you disagree with them. You'd be -5 if that were the case. No wonder so many posts get modded negatively even though they are not breaking the rules (off topic/personal insults.) Learn to moderate...

That said, a stable kernel API doesn't hinder development. Just because one person, obviously biased, says so - doesn't make it true. I'd say dtrace was light years ahead of anything linux has to offer. Same with ZFS. Same with zones. The list goes on.

A stable API just means the development model is different. More time planning, less time hacking together code that semi-works. There's a reason why drivers in linux tend to be flaky, especially ones that are newly introduced. Personally, I'll stick with stability. You can have all the bleeding edge functionality that doesn't/barely/halfway works, I'll happily wait for a stable solution that always/fully works instead.

Different models, different methods, both eventually get to the same point. One is a little more rapid at the expense of a lot of stability, one is a lot more stable at the expense of a little bit of rapidity.