Slashdot Mirror
Should Linux Have a Binary Kernel Driver Layer?
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?
No thanks, this is just a great way to promote closed source inside the linux kernel and to make debugging problems totally impossible.
Shadus
I gave up Linux mostly because I was tired of getting punished for having new hardware, which is often unsupported. Especially on laptops.
If you don't force the manufacturers to include their driver source in the kernel, you might get them to release actual drivers for their new hardware.
Toronto-area transit rider? Rate your ride.
As someone who has tried to install various Linux distributions on RAID cards, and has had difficulty getting installers to use even third-party open-source drivers*, I'd love a binary driver API.
As someone who supports free software, and has struggled with NVIDIA's video drivers (and they're at least trying to meet us halfway by making it as easy as possible to install their closed-source driver under the current system) I can see the negative consequences of encouraging binary-only drivers.
*Example: Promise SX6000. Old cards work with I20, newer ones use their own interface. An open source driver is available, at least for the 2.4 kernel, but good luck if you want to get your installer's kernel to use it. Unless you can create a driver disk, a byzantine task in itself, you're stuck with a few outdated versions of Red Hat, SuSE, and I think TurboLinux.
I am not a linux contributor, but I would think you'd kinda want to guard access to the kernel kinda closely. I mean, sure, anyone can fork it or grab a copy to putz around with, but contributing back into the kernel - that's gotta be just about as stable as a piece of code can be.
Despite some loss in efficiency, I've always been an advocate of abstracted access. To many of the pieces of software we write at my job do we add a logical API, so that we don't always have to open the main code branch every time we want to add a feature.
Driver developers hardly equal kernel developers. Keeping the two logically seperated makes sense - not to mention that driver developers are hardly the only ones that would benefit from this API.
Excuse my speling.
Making The Bar Project
What are his reasons for not putting video card drivers in the kernel, like other Unix operating systems?
Why do we still have to have a user program (X) with device drivers in it? (Would anybody think it's a good idea if the Linux kernel didn't have any sound drivers, and required gstreamer to implement its own?)
It seems we have two competing driver models in Linux: some are in the kernel, and provide a consistent interface (sound cards, SCSI/IDE/... cards, network cards), and some aren't in the kernel at all, but expose them at a low level and rely on userspace programs to provide actual drivers (X11 for video cards, CUPS for printers).
I'm against a binary API, not on philosophical grounds (I like gstreamer's binary API), but because it simply never works: I've tried to use binary-only drivers under Linux in the past, and it never works nearly as well as open-source drivers. But whewher or not you agree with Linus' open-source philosophy, can we at least all agree that we need to put drivers in the same, correct abstraction level?
"....if a vendor doesn't bother to certify the driver (it's not that expensive after all) it's a good indication that they might not care about driver improvement as well...."
or maybe it improves that its drivers so frequently that it cant keep trying to certify it every single time?
There is one thing you all keep leaving out about certified drivers:
Without them you aren't guaranteed support from Microsoft.
If you are running machines with all certified drivers and WMI/MSI installed applications then Microsoft will be right there with you until the problem is solved. You won't find it written anywhere but Microsoft gurantees that you're machine will not crash (BSOD) if you use certified drivers and MSI installed software. At home this isn't possible, but in some environments it is possible (and a good idea in other places).
In a way you are locked in to what Microsoft has approved, but if they've approved it then the problem is theirs to fix - not yours. Good luck meeting those two requirements, but if you can: hold them to it.
Get your Unix fortune now!
I know you're joking, but how about this for an idea:
... rant away open source crazies. ;)
A hybrid kernel. Open source drivers are compiled into the kernel. There is a API for closed-source drivers to run in user-space.
Does not violate GPL.
Little compromise to stability.
Developers who only want to do closed-source drivers can do so.
Developers have incentive to open source their drivers in order to have better performance and take advantage of newer kernel features (the internal APIs are updated with the kernel, the external APIs stay fixed and fall behind the feature curve).
Win.
Win.
Win.
Unless its just a philosophical question, in which case