3 ms·

That's a necessary, but not a sufficient requirement for quality. The driver needs to be both upstreamed and actively maintained obviously, to retain its qualit

by shmerl 8y ago

That's a necessary, but not a sufficient requirement for quality. The driver needs to be both upstreamed and actively maintained obviously, to retain its quality. If you think just getting upstream will magically make it good without any further effort, then you think wrong.

AnIdiotOnTheNet 8y ago
Right, so why force everyone who wants to write a driver to upstream? Just make a stable driver ABI they can interface with and be done with it. If their driver is good, it'll work good, if it isn't, it won't. Same as today really, but without the need to constantly recompile and force people to open their code (like that even matters because, as you said: firmware blobs).
- shmerl 8y ago
  If you don't have both - quality will suffer because developers will make any mess they want without aligning with the kernel. One infamous example is Nvidia's "official" GPU driver. All its problems are caused by it not being upstreamed. > Just make a stable driver ABI they can interface with and be done with it. That will also hold the kernel back. So let the driver better be compatible for some version window, but not forever, even if it's provided with dkms. That's a good, not a bad thing. Freezing driver interfaces forever will turn the kernel itself into a mess. No one does it, including Windows.
  - AnIdiotOnTheNet 8y ago
    > One infamous example is Nvidia's "official" GPU driver. All its problems are caused by it not being upstreamed. Alternative perspective: the lack of any kind of stability in the driver ABI causes all the problems with the nVidia driver. > That will also hold the kernel back. So let the driver better be compatible for some version window, but not forever [...] Who said it had to be forever?
    - shmerl 8y ago
      > Alternative perspective: the lack of any kind of stability in the driver ABI causes all the problems with the nVidia driver. Intel and AMD maintain their drivers upstream, and don't have anything resembling Nvidia's problems (general lack of integration). The later ones are very clearly the result of them refusing to upstream it. To put it differently, Nvidia can make their driver integrated, they just don't want to and it has nothing to do with how fast kernel interfaces are evolving. Case in point, Nvidia do update their dkms exposed parts of the driver, to address kernel changes. If they won't, their driver won't work at all, even through dkms. > Who said it had to be forever? You said "be done with it", which means no one will maintain it expecting it to be forever compatible? Otherwise I'm not sure what your point was.
      - AnIdiotOnTheNet 8y ago
        I'm giving nVidia the benefit of the doubt and assuming they have legitimate reasons for not wanting to open source all their code. That makes this a legitimate conflict, Linux enforces all driver code must be open, and nVidia doesn't want to open their code. No one is at fault per-se, there are two solutions to the problem and neither party is interested in compromise. > You said "be done with it", which means no one will maintain it expecting it to be forever compatible? I don't know why you'd immediately jump to "forever". Nothing is forever. I just meant "a sufficiently long time". Like with Windows APIs, which still have a lot of compatibility with applications compiled 20 years ago.
        shmerl 8y ago
        > I'm giving nVidia the benefit of the doubt and assuming they have legitimate reasons for not wanting to open source all their code. They don't, because there is nouveau already and Nvidia are being rather nasty in preventing it from fully working. See: https://www.phoronix.com/forums/forum/linux-graphics-x-org-drivers/open-source-nvidia-linux-nouveau/998310-nouveau-persevered-in-2017-for-open-source-nvidia-but-2018-could-be-much-better?p=998316#post998316 https://www.phoronix.com/forums/forum/linux-graphics-x-org-d... > Like with Windows APIs, which still have a lot of compatibility with applications compiled 20 years ago. Try using Windows drivers from older Windows kernels with newer Windows. They won't work. So it's not anywhere close to 20 years.

by shmerl 8y ago

AnIdiotOnTheNet 8y ago

Right, so why force everyone who wants to write a driver to upstream? Just make a stable driver ABI they can interface with and be done with it. If their driver is good, it'll work good, if it isn't, it won't. Same as today really, but without the need to constantly recompile and force people to open their code (like that even matters because, as you said: firmware blobs).

shmerl 8y ago
If you don't have both - quality will suffer because developers will make any mess they want without aligning with the kernel. One infamous example is Nvidia's "official" GPU driver. All its problems are caused by it not being upstreamed. > Just make a stable driver ABI they can interface with and be done with it. That will also hold the kernel back. So let the driver better be compatible for some version window, but not forever, even if it's provided with dkms. That's a good, not a bad thing. Freezing driver interfaces forever will turn the kernel itself into a mess. No one does it, including Windows.
- AnIdiotOnTheNet 8y ago
  > One infamous example is Nvidia's "official" GPU driver. All its problems are caused by it not being upstreamed. Alternative perspective: the lack of any kind of stability in the driver ABI causes all the problems with the nVidia driver. > That will also hold the kernel back. So let the driver better be compatible for some version window, but not forever [...] Who said it had to be forever?
  - shmerl 8y ago
    > Alternative perspective: the lack of any kind of stability in the driver ABI causes all the problems with the nVidia driver. Intel and AMD maintain their drivers upstream, and don't have anything resembling Nvidia's problems (general lack of integration). The later ones are very clearly the result of them refusing to upstream it. To put it differently, Nvidia can make their driver integrated, they just don't want to and it has nothing to do with how fast kernel interfaces are evolving. Case in point, Nvidia do update their dkms exposed parts of the driver, to address kernel changes. If they won't, their driver won't work at all, even through dkms. > Who said it had to be forever? You said "be done with it", which means no one will maintain it expecting it to be forever compatible? Otherwise I'm not sure what your point was.
    - AnIdiotOnTheNet 8y ago
      I'm giving nVidia the benefit of the doubt and assuming they have legitimate reasons for not wanting to open source all their code. That makes this a legitimate conflict, Linux enforces all driver code must be open, and nVidia doesn't want to open their code. No one is at fault per-se, there are two solutions to the problem and neither party is interested in compromise. > You said "be done with it", which means no one will maintain it expecting it to be forever compatible? I don't know why you'd immediately jump to "forever". Nothing is forever. I just meant "a sufficiently long time". Like with Windows APIs, which still have a lot of compatibility with applications compiled 20 years ago.
      - shmerl 8y ago
        > I'm giving nVidia the benefit of the doubt and assuming they have legitimate reasons for not wanting to open source all their code. They don't, because there is nouveau already and Nvidia are being rather nasty in preventing it from fully working. See: https://www.phoronix.com/forums/forum/linux-graphics-x-org-drivers/open-source-nvidia-linux-nouveau/998310-nouveau-persevered-in-2017-for-open-source-nvidia-but-2018-could-be-much-better?p=998316#post998316 https://www.phoronix.com/forums/forum/linux-graphics-x-org-d... > Like with Windows APIs, which still have a lot of compatibility with applications compiled 20 years ago. Try using Windows drivers from older Windows kernels with newer Windows. They won't work. So it's not anywhere close to 20 years.