6 ms·

Strong support for rejecting kernel drivers with a proprietary userspace counterpart. Totally violates the spirit of the GPL. I was NACK to this WSL driver, too

Strong support for rejecting kernel drivers with a proprietary userspace counterpart. Totally violates the spirit of the GPL. I was NACK to this WSL driver, too, totally flies in the face of the rest of the Linux graphics stack. Companies should get in the habit of talking to the kernel early, and not just dumping a patchset over the fence and hoping we like it.

chrisseaton 6y ago
Why do companies care if their driver is in the main kernel repository or not? All that matters is if distributions ship it, which they have to if people want their computers to work. Why don't they just say 'take it or leave it.'
- stefan_ 6y ago
  The kernel has no stable interface for device drivers and in fact internal APIs routinely change. If your device driver is in the kernel repository, it will be updated by the people making changes and you get the chance to give feedback.
  - chrisseaton 6y ago
    But again RedHat and Canonical for example can't ship without updating the changed kernel code to match the driver, so can't they leave it to them to fix?
    - bonzini 6y ago
      Red Hat doesn't ship any proprietary module. However, they do list a number of symbols and struct definitions as stable, unlike the upstream kernel, and preserve them for the life of a RHEL major release. This is why RHEL stays on an old kernel release and backports new features to the old release, instead of releasing new kernels.
    - wmf 6y ago
      Red Hat and Canonical aren't suckers; if you dump an infinite maintenance burden on them they will think very hard before accepting it.
      - chrisseaton 6y ago
        What are they going to do? Ship a distribution without proper graphics support?
        wmf 6y ago
        Basically yes. Note that most of the GPU driver problems are on phones and neither RHEL nor Ubuntu officially support phones at all. And there are also many PC components that RHEL/Ubuntu don't support either, although usually that's just because the hardware is too new.
        CoolGuySteve 6y ago
        The wayland login in Ubuntu 18.04 already broke Nvidia's proprietary driver. So yes.
        bonzini 6y ago
        Red Hat ships nouveau. Nvidia is the one that chooses which distros to support (in addition to upstream kernels) and adapts their driver shim if needed.
    - stefan_ 6y ago
      Your mistake is thinking RedHat and Canonical are some sort of players here. The vast vast majority of Linux deployments are not from any sort of Linux distribution company.
      - bonzini 6y ago
        Nvidia makes way more money from Quadro and Tesla cards than from the consumer cards (probably in general, and certainly running on Linux). "Company-made" Linux (including CentOS) is absolutely a player there. Disclaimer, I work for Red Hat.
- matheusmoreira 6y ago
  Companies would then have to maintain the drivers themselves. If I remember correctly, the Linux kernel gets over 20 patches per hour. They have to pay developers to maintain the out-of-tree drivers or get left behind. This is one reason why so many mobile devices run ancient kernels which can't be updated. They stopped maintaining the out-of-tree drivers so people remain permanently stuck on the latest version that still works.
  - deleted 6y ago
    [deleted]
- g_p 6y ago
  Good question. The answer is that it requires you to keep your driver maintained as a patch that applies against the kernel you want to use it on. Every release, there's refactoring and improvements of the kernel subsystems. They don't offer stable APIs (by design) for drivers - you need to keep it up to date. If you want to see this for real, try getting a "code thrown over the wall once" type embedded device kernel tree, figure out the kernel version it shipped on (likely ancient), and try to apply the latest patch level for that release to it. Then resolve the inevitable issues even just applying a few minor bug fixes. Now if you to to update to the next major kernel version, you'll start to find functions your driver tried to call aren't there, or have new function definitions. You need to dig through the code to see what's changed. Over a few major versions, you'll eventually realise this is a whole lot of bother. If you just mainline your driver, you'll no longer need to worry about this costly maintenance burden - it might well be a few engineers spending most of their time on it. That quickly adds up, and suddenly mainlining starts to make sense. Nvidia has to keep updating their proprietary driver every release, and presumably has a few developers doing this. I can't speak for how well it works, as I always go for AMD, but other comments here seem to confirm distributions will happily break Nvidia drivers because they aren't mainline and therefore aren't tested.
  - NullPrefix 6y ago
    > If you just mainline your driver, you'll no longer need to worry about this costly maintenance burden "Pro" move is to just skip the costly maintenance and keep the kernel same, for old times sake.
    - g_p 6y ago
      Yup, and with that, welcome to the world of semi-proprietary ARM development boards. Leave security patches at the door, and enjoy your version 3.5 kernel for as long as the hardware lasts! Joking aside, I think a lot of this comes down to the incentives (or lack thereof) in the ecosystem - there is no real penalty for releasing an insecure product, or one that can't be kept up to date. Thus inventivising shipping on an outdated kernel you can't maintain, and never patching it. If those shipping products had to factor in the externalities of this decision, they would rapidly be mainlining everything to reduce the costs of this. The cost of "mainlining" their code will be trivial compared to the (unmeasured) cost of the disposal of the equipment during a reasonable lifespan due to lacking updates, and the replacement of the equipment.
- imtringued 6y ago
  Distributions with modern kernels can't ship with drivers for old kernels.
monocasa 6y ago
> I was NACK to this WSL driver, too, totally flies in the face of the rest of the Linux graphics stack. Companies should get in the habit of talking to the kernel early, and not just dumping a patchset over the fence and hoping we like it. I guess I'm not sure how much earlier they can bring in the main kernel than a graphics driver that doesn't even display graphics yet. Like I've seen the amount of bikeshedding that happens when talking about hypotheticals with no code to reference. What should they have done differently in your mind?
- ddevault 6y ago
  The problem is that they built an entirely independent graphics stack. It does not co-exist at all with any of the graphics subsystem which has been built up for many drivers and use-cases over the past 5-10 years. What they should have done is approached the community with their idea and sought input on how to design their approach. We would have discussed solutions which integrated better into the existing stack. But, then they would be robbed of the chance to do a big announcement and get ahead of the press cycle with their bad driver.
  - monocasa 6y ago
    I mean, the were actively asking how to better integrate it before it had gotten to the point of displaying graphics, with some mainline kernel devs questioning if it should be integrated with the graphics stack at all, and be pushed back into the hyperv side of things. It's very clearly an RFC with an eye for "how can we better collaborate and who should we collaborate with?" I think they need to better document and support a more opensource stack on the user side of things (maybe a vulkan or mesa targeting the WDDM ioctl interface rather than on the dx12 UAPI), but those are surmountable issues, and makes it look like the amdgpu side of the house.
    - bonzini 6y ago
      It had gotten to the point where you can do machine learning and other CUDA applications, and that brings a lot more money than graphics. WSL is definitely pulling an Embrace Extend Extinguish. I am not saying the new Microsoft is the same as Ballmer's, but still.
Kednicma 6y ago
Wait, since when are you in charge of this part of the kernel?
mappu 6y ago
> Totally violates the spirit of the GPL. In the specific, I think the relevant part is whether the kernel component and the userspace component are an Aggregate or not for the purposes of GPL virality. From the gnu.org GPL FAQ: > Where's the line between two separate programs, and one program with two parts? This is a legal question, which ultimately judges will decide. We believe that a proper criterion depends both on the mechanism of communication (exec, pipes, rpc, function calls within a shared address space, etc.) and the semantics of the communication (what kinds of information are interchanged). If the modules are included in the same executable file, they are definitely combined in one program. If modules are designed to run linked together in a shared address space, that almost surely means combining them into one program. By contrast, pipes, sockets and command-line arguments are communication mechanisms normally used between two separate programs. So when they are used for communication, the modules normally are separate programs. But if the semantics of the communication are intimate enough, exchanging complex internal data structures, that too could be a basis to consider the two parts as combined into a larger program. I agree we're somewhere murky within the last paragraph. The mechanism is separated well enough - the kernel driver is just IOCTLs over a pipe. The semantics are certainly carrying complex internal data structures, however, those data structures aren't part of any GPL program at all. So perhaps it's not really anti-GPL - but it is certainly useless in a fully Free environment.

chrisseaton 6y ago

Why do companies care if their driver is in the main kernel repository or not? All that matters is if distributions ship it, which they have to if people want their computers to work. Why don't they just say 'take it or leave it.'

stefan_ 6y ago
The kernel has no stable interface for device drivers and in fact internal APIs routinely change. If your device driver is in the kernel repository, it will be updated by the people making changes and you get the chance to give feedback.
- chrisseaton 6y ago
  But again RedHat and Canonical for example can't ship without updating the changed kernel code to match the driver, so can't they leave it to them to fix?
  - bonzini 6y ago
    Red Hat doesn't ship any proprietary module. However, they do list a number of symbols and struct definitions as stable, unlike the upstream kernel, and preserve them for the life of a RHEL major release. This is why RHEL stays on an old kernel release and backports new features to the old release, instead of releasing new kernels.
  - wmf 6y ago
    Red Hat and Canonical aren't suckers; if you dump an infinite maintenance burden on them they will think very hard before accepting it.
    - chrisseaton 6y ago
      What are they going to do? Ship a distribution without proper graphics support?
      - wmf 6y ago
        Basically yes. Note that most of the GPU driver problems are on phones and neither RHEL nor Ubuntu officially support phones at all. And there are also many PC components that RHEL/Ubuntu don't support either, although usually that's just because the hardware is too new.
      - CoolGuySteve 6y ago
        The wayland login in Ubuntu 18.04 already broke Nvidia's proprietary driver. So yes.
      - bonzini 6y ago
        Red Hat ships nouveau. Nvidia is the one that chooses which distros to support (in addition to upstream kernels) and adapts their driver shim if needed.
  - stefan_ 6y ago
    Your mistake is thinking RedHat and Canonical are some sort of players here. The vast vast majority of Linux deployments are not from any sort of Linux distribution company.
    - bonzini 6y ago
      Nvidia makes way more money from Quadro and Tesla cards than from the consumer cards (probably in general, and certainly running on Linux). "Company-made" Linux (including CentOS) is absolutely a player there. Disclaimer, I work for Red Hat.
matheusmoreira 6y ago
Companies would then have to maintain the drivers themselves. If I remember correctly, the Linux kernel gets over 20 patches per hour. They have to pay developers to maintain the out-of-tree drivers or get left behind. This is one reason why so many mobile devices run ancient kernels which can't be updated. They stopped maintaining the out-of-tree drivers so people remain permanently stuck on the latest version that still works.
- deleted 6y ago
  [deleted]
g_p 6y ago
Good question. The answer is that it requires you to keep your driver maintained as a patch that applies against the kernel you want to use it on. Every release, there's refactoring and improvements of the kernel subsystems. They don't offer stable APIs (by design) for drivers - you need to keep it up to date. If you want to see this for real, try getting a "code thrown over the wall once" type embedded device kernel tree, figure out the kernel version it shipped on (likely ancient), and try to apply the latest patch level for that release to it. Then resolve the inevitable issues even just applying a few minor bug fixes. Now if you to to update to the next major kernel version, you'll start to find functions your driver tried to call aren't there, or have new function definitions. You need to dig through the code to see what's changed. Over a few major versions, you'll eventually realise this is a whole lot of bother. If you just mainline your driver, you'll no longer need to worry about this costly maintenance burden - it might well be a few engineers spending most of their time on it. That quickly adds up, and suddenly mainlining starts to make sense. Nvidia has to keep updating their proprietary driver every release, and presumably has a few developers doing this. I can't speak for how well it works, as I always go for AMD, but other comments here seem to confirm distributions will happily break Nvidia drivers because they aren't mainline and therefore aren't tested.
- NullPrefix 6y ago
  > If you just mainline your driver, you'll no longer need to worry about this costly maintenance burden "Pro" move is to just skip the costly maintenance and keep the kernel same, for old times sake.
  - g_p 6y ago
    Yup, and with that, welcome to the world of semi-proprietary ARM development boards. Leave security patches at the door, and enjoy your version 3.5 kernel for as long as the hardware lasts! Joking aside, I think a lot of this comes down to the incentives (or lack thereof) in the ecosystem - there is no real penalty for releasing an insecure product, or one that can't be kept up to date. Thus inventivising shipping on an outdated kernel you can't maintain, and never patching it. If those shipping products had to factor in the externalities of this decision, they would rapidly be mainlining everything to reduce the costs of this. The cost of "mainlining" their code will be trivial compared to the (unmeasured) cost of the disposal of the equipment during a reasonable lifespan due to lacking updates, and the replacement of the equipment.
imtringued 6y ago
Distributions with modern kernels can't ship with drivers for old kernels.

monocasa 6y ago

> I was NACK to this WSL driver, too, totally flies in the face of the rest of the Linux graphics stack. Companies should get in the habit of talking to the kernel early, and not just dumping a patchset over the fence and hoping we like it. I guess I'm not sure how much earlier they can bring in the main kernel than a graphics driver that doesn't even display graphics yet. Like I've seen the amount of bikeshedding that happens when talking about hypotheticals with no code to reference. What should they have done differently in your mind?

ddevault 6y ago
The problem is that they built an entirely independent graphics stack. It does not co-exist at all with any of the graphics subsystem which has been built up for many drivers and use-cases over the past 5-10 years. What they should have done is approached the community with their idea and sought input on how to design their approach. We would have discussed solutions which integrated better into the existing stack. But, then they would be robbed of the chance to do a big announcement and get ahead of the press cycle with their bad driver.
- monocasa 6y ago
  I mean, the were actively asking how to better integrate it before it had gotten to the point of displaying graphics, with some mainline kernel devs questioning if it should be integrated with the graphics stack at all, and be pushed back into the hyperv side of things. It's very clearly an RFC with an eye for "how can we better collaborate and who should we collaborate with?" I think they need to better document and support a more opensource stack on the user side of things (maybe a vulkan or mesa targeting the WDDM ioctl interface rather than on the dx12 UAPI), but those are surmountable issues, and makes it look like the amdgpu side of the house.
  - bonzini 6y ago
    It had gotten to the point where you can do machine learning and other CUDA applications, and that brings a lot more money than graphics. WSL is definitely pulling an Embrace Extend Extinguish. I am not saying the new Microsoft is the same as Ballmer's, but still.

Kednicma 6y ago

Wait, since when are you in charge of this part of the kernel?

mappu 6y ago

> Totally violates the spirit of the GPL. In the specific, I think the relevant part is whether the kernel component and the userspace component are an Aggregate or not for the purposes of GPL virality. From the gnu.org GPL FAQ: > Where's the line between two separate programs, and one program with two parts? This is a legal question, which ultimately judges will decide. We believe that a proper criterion depends both on the mechanism of communication (exec, pipes, rpc, function calls within a shared address space, etc.) and the semantics of the communication (what kinds of information are interchanged). If the modules are included in the same executable file, they are definitely combined in one program. If modules are designed to run linked together in a shared address space, that almost surely means combining them into one program. By contrast, pipes, sockets and command-line arguments are communication mechanisms normally used between two separate programs. So when they are used for communication, the modules normally are separate programs. But if the semantics of the communication are intimate enough, exchanging complex internal data structures, that too could be a basis to consider the two parts as combined into a larger program. I agree we're somewhere murky within the last paragraph. The mechanism is separated well enough - the kernel driver is just IOCTLs over a pipe. The semantics are certainly carrying complex internal data structures, however, those data structures aren't part of any GPL program at all. So perhaps it's not really anti-GPL - but it is certainly useless in a fully Free environment.