Do we really need that many kernel developers? I'm getting the impression that a lot of dev power is wasted just to maintain drivers that should be produced by hardware vendors. The vendors won't do that because there's no stable ABI, which means that people need to reinvent the wheel.
One could argue that it adds better quality control and all in all, we get open source implementations of what would instead be proprietary drivers, but in the end, complex drivers aren't good enough anyway (see Nouveau). As for quality control... many say that Linus's view on security is questionable. For one, I don't like the concept of pluggable /stackable security mechanisms (selinux, apparmor, etc) where one consistent system would do. It just feels cluttered.
> I'm getting the impression that a lot of dev power is wasted just to maintain drivers
No. Maintenance of in-tree drivers is done mostly by subsystems maintainers, in automated fashion (see http://coccinelle.lip6.fr/). Including API/ABI-breaking changes. But nobody notices, because it all goes at once, in sync.
> that should be produced by hardware vendors
Yep, vendors should. But only few of them do it properly. Most of vendors fall into such shameful categories:
- who don't publish drivers sources at all, violating GPL;
- who don't care about quality and just feel fine with their utter crap of code, based on ages-old kernel and buggy drivers full of braindead things; also, no updates and no forward-ports;
- who, in addition to above, distribute only obfuscated sources.
Stable ABI would help only to those bad actors who are enemies of user freedom and don't share sources. Nobody else is having a problem with unstable ABI.
> I don't like the concept of pluggable /stackable security mechanisms (selinux, apparmor, etc) where one consistent system would do. It just feels cluttered.
There was, and still is, lack of coherence in community views on what is best. I believe pluggable security modules is the best possible way to give freedom to everybody.
Edit: In particular, there not being a stable ABI prevents vendors from re-inventing various wheels because they can just argue for and submit enhancements and changes to various core kernel subsystems so that they better match the requirements of their hardware / driver, instead of putting extra code into every driver like they have to do on other systems where they have to live with whatever ABI was declared stable by the OS vendor a decade ago.
> In particular, there not being a stable ABI prevents vendors from re-inventing various wheels
Here it depends on what you consider as "wheel": If a hardware vendor has to write two versions of the driver (one using the existing wheel in the Linux kernel and one with an own wheel on other OSes (Windows, OS X)) this clearly leads to reinventing various wheels. On the other hand inside the Linux kernel there is only one subsystem wheel that is used by all drivers using it instead of reinventing this wheel for all drivers of some fixed type.
NVIDIA's huge blob is probably a case where they re-invented lots of wheels in order to share the same driver between different OSes. For something as complicated as a modern GPU driver, this could well make sense from an engineering point of view (legal objections notwithstanding).
On the other hand, 10 years ago there were various out-of-tree Linux WLAN drivers, and each of them contained a full independently developed 802.11 stack, perhaps one shared across drivers for multiple OSes by the same vendor - surely having this much duplication of generic infrastructure that dwarfs the actual model-specific part of the drivers is quite pointless.
IMHO only GPUs have an inherent complexity that is high enough that one could think about alternatives to just using the shared infrastructure that's already in Linux. But even in this area you see companies like AMD moving towards a Linux-specific kernel driver approach with their new "amdgpu" driver.
@the_why_of_y: what should I note here? That some vendors do that within the source tree? Yes, some do, but many don't, including a fair share of smaller ones.
This sadly true, but I don't see how this is caused by lack of a stable ABI, more likely you'll see justifications such as "we need to protect our intellectual properteh", management at hardware vendors not understanding the development process, or just not caring about a niche market (in case of desktop/laptop hardware).
The vendors "should" be shipping open source drivers. That's why there's no stable ABI. They're quite at liberty to submit drivers - and then kernel devs can maintain them!
(Obviously not everyone agrees with this, but that's the point of GPL/copyleft licensing)
>The vendors won't do that because there's no stable ABI
That only causes problems for vendors who only supplies proprietary drivers, of which there are very few these days (only ones I've personally come across are NVidia and Broadcom), and it's not as if the unstable ABI prevents them from supporting Linux either, since they do.
Beyond that, reasons for why you'd want open source drivers are many, like the kernel devs being able to figure out and fix problems without having to rely on a third party (vendor), upgrade drivers to make use of new kernel functionality without waiting for the vendor to comply/agree, being able to audit them for security problems, being able to port them to every platform on which Linux runs, which includes platforms which the hardware vendor might not think worthwile to support, and of course other systems alltogether like the BSD's (stable ABI sure didn't get them more proprietary drivers), fringe OS'es like Haiku, Minix etc.
So no, the answer is not to lose the flexibility of a changeable ABI, but to have vendors either supply fully open source drivers or the documentation necessary for creating open source drivers, which is pretty much the situation we have today, again with a few aforementioned holdouts.
Do we really need that many kernel developers? I'm getting the impression that a lot of dev power is wasted just to maintain drivers that should be produced by hardware vendors. The vendors won't do that because there's no stable ABI, which means that people need to reinvent the wheel.
One could argue that it adds better quality control and all in all, we get open source implementations of what would instead be proprietary drivers, but in the end, complex drivers aren't good enough anyway (see Nouveau). As for quality control... many say that Linus's view on security is questionable. For one, I don't like the concept of pluggable /stackable security mechanisms (selinux, apparmor, etc) where one consistent system would do. It just feels cluttered.