4 ms·

Thank you for the explanation and the link to that article. I disagree with some of the philosophical statements, like: > While in theory it is possible to hav

by euyyn 10y ago

Thank you for the explanation and the link to that article. I disagree with some of the philosophical statements, like: > While in theory it is possible to have a stable API, in practice real life is more complicated. (In practice it's also possible, as Microsoft demonstrated with Windows for decades). or (from the article): > benefits if your driver is in the main kernel tree, all of which has made Linux into such a strong, stable, and mature operating system which is the reason you are using it in the first place (The reality is, that wasn't enough of a reason to move users from Windows, before the smartphone era. Nor is it the reason Linux won over Windows in the smartphone market, either.) I think the article hits the crux of the issue, though: Nobody wants to spend their free time contributing to maintain an old interface, instead of working on the new one. A side effect of this policy is a better kernel, granted (for the devices that actually make it to the main tree). So given that a stable API isn't an option, and the current model is clearly not working, I guess the solution lies in solving the hurdles these companies face to upstream their code. Do you know about that, or where could I learn more?

rogerbinns 10y ago
Microsoft only had to support one architecture, and continuously changed driver models. Except 32 and 64 bit. Plus you can't use drivers across Windows versions that much. But at the end of the day it was a financial decision by them to maintain a very large degree of backwards compatibility, and by their customers to pay that price. But also remember just how "sticky" Windows 98, XP etc were. People wouldn't give them up. Also have you tried to use USB 3 on Windows 7? Or how about skylake until the backpedal? Note that with Linux you can get more a semblance of Microsoft style stability. Use RHEL (redhat enterprise linux) and they do the work of backporting relevant drivers and changes. You also get to pay handsomely for that. Note that the majority of devices do make it to the kernel. You can plug in virtually anything and it works! You really should read LWN. They do a fantastic job of covering various issues. For example here is an article on hurdles: https://lwn.net/Articles/647524/ https://lwn.net/Articles/647524/
- euyyn 10y ago
  With this: > Note that with Linux you can get more a semblance of Microsoft style stability. Use RHEL (redhat enterprise linux) and they do the work of backporting relevant drivers and changes. You also get to pay handsomely for that. > Note that the majority of devices do make it to the kernel. You can plug in virtually anything and it works! it looks like you're mostly thinking of the server space. The problem of manufacturers forking the kernel, and the topic of this HN post in general, is on Android. E.g. my last two phones, a Samsung Galaxy Nexus, and an LG Nexus 5, won't get any more OS updates. I'm going to read that article, and check LWN regularly.
  - rogerbinns 10y ago
    No, the majority of devices do really work. Plug in a random webcam, drive controller, spi peripheral etc. Embedded systems are different, but it isn't the device driver support that is the problem. x86 has a mostly standardised architecture, and due to an accident of history has a I/O address space that is separate from memory address space. Consequently it has been possible to probe for devices with very low probability of collateral damage. Which is why Linux and Windows can "just work" on virtually any x86 system. In the ARM world, you get the CPU design itself from ARM and copy/paste that into your design program. Then you copy/paste in other pieces you want such as memory controllers, USB controllers, serial ports, displays, storage, SPI, and whatever else fits your needs. Then you hit print and get chips with all that working together. There is no separate I/O address space, so these devices all end up in memory address space. There is no standard location for them. Somehow you have to know the USB controller is at address 0x12345678, and you can't practically scan the address space trying to find all possible devices, and certainly not without collateral damage. So what would happen is system developers would fork the current kernel, and make a permutation of an existing system but with hardcoded knowledge of where all the pieces making up the system live in the address space, and how they are connected. Then they'd add support for unique devices, connections, quirks and bugs. Throw in some binary blobs, NDAs, "IP" etc and they now have their own unique kernel. And that is why they get stuck on a kernel version that can't be practically updated. The kernel developers adopted device trees as a solution. This is provides a data description to the kernel at boot time of what platform devices are present, how they are connected and where to find them. That allows the same kernel binary to support a very wide range of hardware. ARM64 systems also typically require ACPI, which if you squint allows the platform to also provide code that can run for dealing with the platform. What this means is that the problem has been addressed technically. It does not address financial issues: the vendors get no more money after first sale, so they don't care about updates. It also does not address the folks doing binary blobs, NDAs and other "IP" concerns. The Linux (GPL) attitude is all about user freedom (as in freedom of speech), and gives everyone participating an equal playing field (no party has a special position).
voltagex_ 10y ago
Two groups probably have more experience in that than others: Linaro: https://www.linaro.org/ https://www.linaro.org/ OpenWRT: https://www.openwrt.org/ https://www.openwrt.org/ Going on a bit of a tangent: Most of the time these companies just don't care. If you don't mind getting your hands dirty, then have a look at some vendor kernel trees. For example, a $300AUD router released last year is running 2.6.34brcm - http://www.tp-link.com.au/download/Archer-D9.html#GPL-Code http://www.tp-link.com.au/download/Archer-D9.html#GPL-Code The 802.11AC card in that router will likely never have open source drivers. I'm pretty sure the routing engine is closed source too, although with 2x Cortex A9 chips I would have thought you could get away with doing it in software.
wtallis 10y ago
> (In practice it's also possible, as Microsoft demonstrated with Windows for decades). There may be a handful of narrow cases where Microsoft has preserved third-party driver compatibility across long spans of time, but when looking across a decade or more, they break as much as they preserve. Consider DirectX, which is now completely antithetical to its original purpose and name of allowing applications (games) relatively direct hardware access. Modern systems can't survive without a level of hardware abstraction and sharing that mid-90s systems couldn't afford. The end result is that you get essentially no hardware accelerated graphics on decade-old GPUs anymore, except where the drivers were re-written for recent versions of Windows. Vista's new audio subsystem killed off an entire product segment of hardware-accelerated audio processing.
- euyyn 10y ago
  Oh, I meant the demonstration has lasted decades, not necessarily that the backwards-compatibility was eternal. Once you take the stance of preserving compatibility, there's a strong market force to deprecate and eliminate old interfaces and guarantees once it's practical. On both the PC market of then, and the smartphone market of today, hardware gets replaced faster than once per decade.

by euyyn 10y ago

rogerbinns 10y ago

Microsoft only had to support one architecture, and continuously changed driver models. Except 32 and 64 bit. Plus you can't use drivers across Windows versions that much. But at the end of the day it was a financial decision by them to maintain a very large degree of backwards compatibility, and by their customers to pay that price. But also remember just how "sticky" Windows 98, XP etc were. People wouldn't give them up. Also have you tried to use USB 3 on Windows 7? Or how about skylake until the backpedal? Note that with Linux you can get more a semblance of Microsoft style stability. Use RHEL (redhat enterprise linux) and they do the work of backporting relevant drivers and changes. You also get to pay handsomely for that. Note that the majority of devices do make it to the kernel. You can plug in virtually anything and it works! You really should read LWN. They do a fantastic job of covering various issues. For example here is an article on hurdles: https://lwn.net/Articles/647524/ https://lwn.net/Articles/647524/

euyyn 10y ago
With this: > Note that with Linux you can get more a semblance of Microsoft style stability. Use RHEL (redhat enterprise linux) and they do the work of backporting relevant drivers and changes. You also get to pay handsomely for that. > Note that the majority of devices do make it to the kernel. You can plug in virtually anything and it works! it looks like you're mostly thinking of the server space. The problem of manufacturers forking the kernel, and the topic of this HN post in general, is on Android. E.g. my last two phones, a Samsung Galaxy Nexus, and an LG Nexus 5, won't get any more OS updates. I'm going to read that article, and check LWN regularly.
- rogerbinns 10y ago
  No, the majority of devices do really work. Plug in a random webcam, drive controller, spi peripheral etc. Embedded systems are different, but it isn't the device driver support that is the problem. x86 has a mostly standardised architecture, and due to an accident of history has a I/O address space that is separate from memory address space. Consequently it has been possible to probe for devices with very low probability of collateral damage. Which is why Linux and Windows can "just work" on virtually any x86 system. In the ARM world, you get the CPU design itself from ARM and copy/paste that into your design program. Then you copy/paste in other pieces you want such as memory controllers, USB controllers, serial ports, displays, storage, SPI, and whatever else fits your needs. Then you hit print and get chips with all that working together. There is no separate I/O address space, so these devices all end up in memory address space. There is no standard location for them. Somehow you have to know the USB controller is at address 0x12345678, and you can't practically scan the address space trying to find all possible devices, and certainly not without collateral damage. So what would happen is system developers would fork the current kernel, and make a permutation of an existing system but with hardcoded knowledge of where all the pieces making up the system live in the address space, and how they are connected. Then they'd add support for unique devices, connections, quirks and bugs. Throw in some binary blobs, NDAs, "IP" etc and they now have their own unique kernel. And that is why they get stuck on a kernel version that can't be practically updated. The kernel developers adopted device trees as a solution. This is provides a data description to the kernel at boot time of what platform devices are present, how they are connected and where to find them. That allows the same kernel binary to support a very wide range of hardware. ARM64 systems also typically require ACPI, which if you squint allows the platform to also provide code that can run for dealing with the platform. What this means is that the problem has been addressed technically. It does not address financial issues: the vendors get no more money after first sale, so they don't care about updates. It also does not address the folks doing binary blobs, NDAs and other "IP" concerns. The Linux (GPL) attitude is all about user freedom (as in freedom of speech), and gives everyone participating an equal playing field (no party has a special position).

voltagex_ 10y ago

Two groups probably have more experience in that than others: Linaro: https://www.linaro.org/ https://www.linaro.org/ OpenWRT: https://www.openwrt.org/ https://www.openwrt.org/ Going on a bit of a tangent: Most of the time these companies just don't care. If you don't mind getting your hands dirty, then have a look at some vendor kernel trees. For example, a $300AUD router released last year is running 2.6.34brcm - http://www.tp-link.com.au/download/Archer-D9.html#GPL-Code http://www.tp-link.com.au/download/Archer-D9.html#GPL-Code The 802.11AC card in that router will likely never have open source drivers. I'm pretty sure the routing engine is closed source too, although with 2x Cortex A9 chips I would have thought you could get away with doing it in software.

wtallis 10y ago

> (In practice it's also possible, as Microsoft demonstrated with Windows for decades). There may be a handful of narrow cases where Microsoft has preserved third-party driver compatibility across long spans of time, but when looking across a decade or more, they break as much as they preserve. Consider DirectX, which is now completely antithetical to its original purpose and name of allowing applications (games) relatively direct hardware access. Modern systems can't survive without a level of hardware abstraction and sharing that mid-90s systems couldn't afford. The end result is that you get essentially no hardware accelerated graphics on decade-old GPUs anymore, except where the drivers were re-written for recent versions of Windows. Vista's new audio subsystem killed off an entire product segment of hardware-accelerated audio processing.

euyyn 10y ago
Oh, I meant the demonstration has lasted decades, not necessarily that the backwards-compatibility was eternal. Once you take the stance of preserving compatibility, there's a strong market force to deprecate and eliminate old interfaces and guarantees once it's practical. On both the PC market of then, and the smartphone market of today, hardware gets replaced faster than once per decade.