7 ms·

How real is the risk? ZFS on Linux is loaded via DKMS. DKMS is basically the compile-from-source alternative to binary blob drivers. Is there a reason to belie

How real is the risk? ZFS on Linux is loaded via DKMS. DKMS is basically the compile-from-source alternative to binary blob drivers. Is there a reason to believe that ZFS via DKMS is materially different, legally, to Nvidia drivers being loaded via binary modules? Indeed it appears that Nvidia proprietary drivers these days go via the DKMS route. Are they also at risk?

detaro 8y ago
The post isn't talking about legal risk?
- barrkel 8y ago
  That's exactly what I'm asking. How real is the risk to Nvidia of using DKMS? It seems like an exactly parallel situation to me. (PS: further, I don't think you can separate out the legal risk from attitude / API risk, because of things like this, mentioned elsewhere in this conversation: https://marc.info/?l=linux-kernel&m=154722999728768&w=2 https://marc.info/?l=linux-kernel&m=154722999728768&w=2 - specifically marking symbols GPL to make them non-available.)
  - joecot 8y ago
    The risk to Nvidia is much lower than ZoL -- Nvidia has the resources to keep up with the kernel. It's maintained in house by the company selling the cards, and they have the resources directly to do development. But just like ZoL, if the Kernel makes more and more breaking changes, Nvidia would eventually make the business decision to cut the proprietary driver loose. However that threshold is likely much higher for a profitable company than a community funded project. But the real price of being an external module is very clear for Nvidia proprietary driver issues. If you look at distro and kernel bug reports, you'll see piles of reports for Nvidia driver users, which devs won't look into because of the tainted kernel. Some Linux software even blacklists Nvidia driver users from using graphics hardware acceleration for their apps, because it causes so many bugs. Nvidia is operating outside of the open source ecosystem, which means they don't benefit from that ecosystem like open source implementations do. When an Nvidia driver user runs into a bug, they're usually just told to shove off and not use the driver.
joecot 8y ago
The risk is in trying to keep compatible with the Linux Kernel, when not part of the Linux Kernel dev team. If ZFS was a module within the Linux kernel source tree, Linux kernel devs would keep it in mind when making changes to the Linux kernel's APIs. They wouldn't make potentially breaking changes to that API, or replace APIs with ones that can't be made compatible with ZFS at all, without considering the effect it would have on ZFS. The Kernel devs have to take the whole tree into account, including all the modules. But since ZoL is not part of the kernel, and is instead a separate independent module that gets loaded into the kernel, the ZoL have to play catch up. Instead of Kernel devs working with them to make sure things stay compatible, or giving them a heads up when something needs to be changed for a new version, the ZoL team is on the outside, trying to make sure they don't get boxed out of the Kernel API. It can be a tenuous position to be in. For a more everyday example, look at the Firefox and Chromium browser updates. For Firefox Quantum they completely revamped their extensions system, making all existing extensions worthless. Either the extension devs rewrote them with the new API, or the extension is just gone. Similarly Chromium is changing its API for how extensions can interact with the DOM and networking, which would make Ublock unusable. If these features were officially part of the browser or official extensions, the browser devs would work with the extension devs to make sure things stayed working; instead the extension developers need to keep up or watch their product die. If the Linux Kernel completely changed its module API, and ZoL was caught flat footed and needed to make substantial rewrites, what would the projects backers do? Would they commit the dev time and resources needed to make those changes, or would they compare the benefits of ZFS vs the competition -- solutions based on btrfs or LVM, both built into the kernel -- and decide to jump ship before committing more time? That's where the danger really lies. If the Linux Kernel makes a serious breaking change, ZoL's supporters might double down to fix it, or they might just cut their losses. And while there is an official way to integrate external filesystems into the Linux kernel, FUSE, it's extremely slow compared to Kernel native modules. There was a userland FUSE implementation of ZFS, and there's a reason it's fallen out of favor. ZoL is significantly faster because of its direct kernel extension, but it's playing with fire by not being part of the kernel tree itself.
- sandGorgon 8y ago
  https://lkml.org/lkml/2018/8/3/621 https://lkml.org/lkml/2018/8/3/621 > Yeah, HELL NO! Guess what? You're wrong. YOU ARE MISSING THE #1 KERNEL RULE. We do not regress, and we do not regress exactly because your are 100% wrong. And the reason you state for your opinion is in fact exactly WHY you are wrong. Your "good reasons" are pure and utter garbage. The whole point of "we do not regress" is so that people can upgrade the kernel and never have to worry about it. -Linus Torvalds
rcthompson 8y ago
My understanding is that Nvidia's non-open source drivers are a pre-compiled binary blob that uses DKMS to compile a wrapper whose only purpose is to re-export existing kernel functionality in a questionably legal attempt to sidestep the GPL requirement. So that's completely different from any module that's actually compiled from source via DKMS.
- snuxoll 8y ago
  There’s no questional legality, and end-user can do whatever they want with GPL software. As long as the modules aren’t bundled with the kernel or on the same media the GPL is perfectly happy with the arrangement.
  - rcthompson 8y ago
    End users aren't the ones accused of violating the GPL. The issue is the non-GPL binary NVidia drivers linking against the GPL kernel without releasing the source code.
ratling 8y ago
It's more compatibility. I've had the DKMS modules break on what were supposed to be minor API compliant kernel upgrades on a major distro. The code was then not fixed for a month (our fix was to rollback kernel versions and just tag it there, it's since been removed entirely). Soured me on using ZFS for Linux at all in production.

detaro 8y ago

The post isn't talking about legal risk?

barrkel 8y ago
That's exactly what I'm asking. How real is the risk to Nvidia of using DKMS? It seems like an exactly parallel situation to me. (PS: further, I don't think you can separate out the legal risk from attitude / API risk, because of things like this, mentioned elsewhere in this conversation: https://marc.info/?l=linux-kernel&m=154722999728768&w=2 https://marc.info/?l=linux-kernel&m=154722999728768&w=2 - specifically marking symbols GPL to make them non-available.)
- joecot 8y ago
  The risk to Nvidia is much lower than ZoL -- Nvidia has the resources to keep up with the kernel. It's maintained in house by the company selling the cards, and they have the resources directly to do development. But just like ZoL, if the Kernel makes more and more breaking changes, Nvidia would eventually make the business decision to cut the proprietary driver loose. However that threshold is likely much higher for a profitable company than a community funded project. But the real price of being an external module is very clear for Nvidia proprietary driver issues. If you look at distro and kernel bug reports, you'll see piles of reports for Nvidia driver users, which devs won't look into because of the tainted kernel. Some Linux software even blacklists Nvidia driver users from using graphics hardware acceleration for their apps, because it causes so many bugs. Nvidia is operating outside of the open source ecosystem, which means they don't benefit from that ecosystem like open source implementations do. When an Nvidia driver user runs into a bug, they're usually just told to shove off and not use the driver.

joecot 8y ago

The risk is in trying to keep compatible with the Linux Kernel, when not part of the Linux Kernel dev team. If ZFS was a module within the Linux kernel source tree, Linux kernel devs would keep it in mind when making changes to the Linux kernel's APIs. They wouldn't make potentially breaking changes to that API, or replace APIs with ones that can't be made compatible with ZFS at all, without considering the effect it would have on ZFS. The Kernel devs have to take the whole tree into account, including all the modules. But since ZoL is not part of the kernel, and is instead a separate independent module that gets loaded into the kernel, the ZoL have to play catch up. Instead of Kernel devs working with them to make sure things stay compatible, or giving them a heads up when something needs to be changed for a new version, the ZoL team is on the outside, trying to make sure they don't get boxed out of the Kernel API. It can be a tenuous position to be in. For a more everyday example, look at the Firefox and Chromium browser updates. For Firefox Quantum they completely revamped their extensions system, making all existing extensions worthless. Either the extension devs rewrote them with the new API, or the extension is just gone. Similarly Chromium is changing its API for how extensions can interact with the DOM and networking, which would make Ublock unusable. If these features were officially part of the browser or official extensions, the browser devs would work with the extension devs to make sure things stayed working; instead the extension developers need to keep up or watch their product die. If the Linux Kernel completely changed its module API, and ZoL was caught flat footed and needed to make substantial rewrites, what would the projects backers do? Would they commit the dev time and resources needed to make those changes, or would they compare the benefits of ZFS vs the competition -- solutions based on btrfs or LVM, both built into the kernel -- and decide to jump ship before committing more time? That's where the danger really lies. If the Linux Kernel makes a serious breaking change, ZoL's supporters might double down to fix it, or they might just cut their losses. And while there is an official way to integrate external filesystems into the Linux kernel, FUSE, it's extremely slow compared to Kernel native modules. There was a userland FUSE implementation of ZFS, and there's a reason it's fallen out of favor. ZoL is significantly faster because of its direct kernel extension, but it's playing with fire by not being part of the kernel tree itself.

sandGorgon 8y ago
https://lkml.org/lkml/2018/8/3/621 https://lkml.org/lkml/2018/8/3/621 > Yeah, HELL NO! Guess what? You're wrong. YOU ARE MISSING THE #1 KERNEL RULE. We do not regress, and we do not regress exactly because your are 100% wrong. And the reason you state for your opinion is in fact exactly WHY you are wrong. Your "good reasons" are pure and utter garbage. The whole point of "we do not regress" is so that people can upgrade the kernel and never have to worry about it. -Linus Torvalds

rcthompson 8y ago

My understanding is that Nvidia's non-open source drivers are a pre-compiled binary blob that uses DKMS to compile a wrapper whose only purpose is to re-export existing kernel functionality in a questionably legal attempt to sidestep the GPL requirement. So that's completely different from any module that's actually compiled from source via DKMS.

snuxoll 8y ago
There’s no questional legality, and end-user can do whatever they want with GPL software. As long as the modules aren’t bundled with the kernel or on the same media the GPL is perfectly happy with the arrangement.
- rcthompson 8y ago
  End users aren't the ones accused of violating the GPL. The issue is the non-GPL binary NVidia drivers linking against the GPL kernel without releasing the source code.

ratling 8y ago

It's more compatibility. I've had the DKMS modules break on what were supposed to be minor API compliant kernel upgrades on a major distro. The code was then not fixed for a month (our fix was to rollback kernel versions and just tag it there, it's since been removed entirely). Soured me on using ZFS for Linux at all in production.