3 ms·

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

by kazarov 10y ago

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.

bnastic 10y ago
It's exactly opposite with Linux, where stable kernel API/ABI are avoided as a matter of principle
- tracker1 10y ago
  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 10y ago
    >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 10y ago
  That's a stable internal kernel API/ABI that's not provided. The stable external (userspace-facing) ABI is very much maintained.
  - wolfgke 10y ago
    But the internal APIs are what driver programmers usually care about. So your argument is void.
    - detaro 10y ago
      I don't think it was argument, just a clarification for readers.
- Qwertious 10y ago
  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 https://lkml.org/lkml/2012/12/23/75
foota 10y ago
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-February/100735.html https://lists.freedesktop.org/archives/dri-devel/2016-Februa...
wtallis 10y ago
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 10y ago
  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 10y ago
    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/ https://lwn.net/Articles/454390/ [1] https://lwn.net/Articles/705884/ https://lwn.net/Articles/705884/ [2] https://www.linuxplumbersconf.org/2016/ocw//system/presentations/4089/original/2016-11-02-rtl8xxxu-presentation.pdf https://www.linuxplumbersconf.org/2016/ocw//system/presentat...

by kazarov 10y ago

bnastic 10y ago

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

tracker1 10y ago
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 10y ago
  >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 10y ago
That's a stable internal kernel API/ABI that's not provided. The stable external (userspace-facing) ABI is very much maintained.
- wolfgke 10y ago
  But the internal APIs are what driver programmers usually care about. So your argument is void.
  - detaro 10y ago
    I don't think it was argument, just a clarification for readers.
Qwertious 10y ago
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 https://lkml.org/lkml/2012/12/23/75

foota 10y ago

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-February/100735.html https://lists.freedesktop.org/archives/dri-devel/2016-Februa...

wtallis 10y ago

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 10y ago
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 10y ago
  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/ https://lwn.net/Articles/454390/ [1] https://lwn.net/Articles/705884/ https://lwn.net/Articles/705884/ [2] https://www.linuxplumbersconf.org/2016/ocw//system/presentations/4089/original/2016-11-02-rtl8xxxu-presentation.pdf https://www.linuxplumbersconf.org/2016/ocw//system/presentat...