[foota]

I think the idea is that the kernel maintainers can't break the code that the AMD driver relies on and in order to properly do that they need to be able to easily grok all the driver implementations, and abstraction layers make that more difficult.

[kazarov]

I don't know anything about linux display architecture, but this point sounds really weird to me from general software engineering perspective. Isn't one of the goals of having drivers in an OS to establish a formalized interface between drivers and kernel, and thus achieve separation of concerns between driver maintainers and kernel maintainers? Requiring that kernel maintainers understand how all drivers work does not sound very scalable.

[wtallis]

Linux developers want to be able to share code across drivers for similar devices, and they want to be able to refactor and improve that shared code without worrying about out-of-tree drivers. That strategy has worked well for eg. WiFi drivers where the shared mac80211 subsystem allows a lot of logic to be pulled out of individual NIC drivers, and improvements to mac80211 more or less automatically benefit all participating drivers.

[kazarov]

Makes sense, but it doesn't have to be mutually exclusive. It is possible to have a fixed network driver interface, and some common helpers orthogonal to it. This way driver developers could chose whether to benefit from common code or not. I guess if linux developer want to enforce code sharing, this wouldn't work, but I wonder why they would do it. Seems like it just makes life harder for both parties.

[wtallis]

Many network drivers in Linux do opt out of the common frameworks, and changes like BQL [0] and some of the recent WiFi restructuring [1] that require driver-level modifications are usually not introduced as a mandatory compatibility break that requires modifying every driver at once.

Sometimes drivers opt out because the hardware is odd enough that it needs to do things differently, or because it offloads to hardware (or proprietary firmware) functionality that is usually done in software. But often, it's just because a driver was written in isolation by the manufacturer and then dumped on the community. (See [2], from the comments in [1], about the work required to clean up some Realtek WiFi drivers enough to be merged to the kernel staging area.) If a driver unnecessarily opts out of common frameworks and does things internally and differently, it can be hard to even evaluate whether problems fixed in the standard frameworks exist in the special snowflake drivers. Even after identifying a problem, the recipes that worked to fix the standard drivers won't apply.

[0] https://lwn.net/Articles/454390/

[1] https://lwn.net/Articles/705884/

[2] https://www.linuxplumbersconf.org/2016/ocw//system/presentat...

[vidarh]

Linux very intentionally and explicitly do not guarantee a stable interface for drivers. If you want to maintain your driver out of tree, then that's your right, but you have to be prepared for Linux kernel maintainers to break your driver regularly. The point is they are not interested in sacrificing ability to improve the kernel just in order to make it easier for people to maintain proprietary drivers.

Proprietary drivers are tolerated, not liked, and people aren't interested in making it easier for them.

[dahauns]

Except that this is in no way specific to proprietary drivers. Lack of a stable interface makes maintaining ALL drivers harder.

[wtallis]

These interfaces aren't broken gratuitously. They change to accommodate new features or to allow for better code reuse within the kernel. In the long term it's only a significant maintenance burden compared to letting the driver stagnate and never gain new functionality or optimization after initial release. Manufacturers might prefer that development model since it helps sell more chips of the next generation, but it's really not what should be used as the baseline.

[prodigal_erik]

You only have to fix your driver if it's outside the kernel tree. Drivers in the tree get fixed by whoever's making the breaking change (which is why it's important that certain hackers be able to read and understand all related drivers).

[bnastic]

It's exactly opposite with Linux, where stable kernel API/ABI are avoided as a matter of principle

[Qwertious]

Internal API/ABI is broken regularly, but Linus is fairly clear on the subject of breaking userspace - https://lkml.org/lkml/2012/12/23/75

[tracker1]

I wouldn't say avoided.. A lot of the interfaces are still compatible with prior versions as is the software that runs on it, or we'd be on Kernel v50+ by now. Not all software, but a bit.

That said, the community isn't afraid of breaking changes to push future versions forward.

[mixedCase]

>A lot of the interfaces are still compatible with prior versions as is the software that runs on it, or we'd be on Kernel v50+ by now.

Linux doesn't follow SemVer.

[caf]

That's a stable internal kernel API/ABI that's not provided. The stable external (userspace-facing) ABI is very much maintained.

[wolfgke]

But the internal APIs are what driver programmers usually care about. So your argument is void.

[detaro]

I don't think it was argument, just a clarification for readers.

[foota]

I agree that this is how it seems it should be. I was mostly basing my comment off of this: https://lists.freedesktop.org/archives/dri-devel/2016-Februa...

[d1str0]

Thank you. This comment clarifies things quite a bit for me.