Proposal: Providing ZFS as DKMS #12

New Issue

thefossguy · 2024-03-08T12:27:34Z

thefossguy commented

2024-03-08 12:27:34 +00:00

Let met start with I am not a lawyer.

ZFS' CDDL license forbids from anyone distributing ZFS kernel module as a binary. The workaround to this is distributing ZFS kernel-space code as DKMS and user-space utilities as compiled binaries. Almost everyone other than Ubuntu does this.

One of Oracle's representative did say that shipping compiled kernel modules is okay because "We didn't sue Canonical for this." Reference: RHEL Panel Discussion at FOSSY 2023, at timestamp 37:30.

And the OpenZFS developers already do that for el8 and el9. But that's done only for x86_64. As a result, folks that want to use ZFS with Rocky Linux, on architectures like AArch64, need to switch to Ubuntu/Debian.

I'd like if we did something to tackle this and documented it. I'd also like to inform our sponsors like 45Drives about it so they can also update their documentation likewise.

A few days ago, when I watched the linked video, I created a COPR repository for ZFS and built packages, installed on my Rock 5B and ran the included ZFS test (part of the zfs-test package). And, the test passed. The SPEC files are already available in the ZFS repository, inside the rpm/redhat directory as .spec.ac files. All we need to do is replace strings @[A-Z]+@ with appropriate values and voila, we have a usable SPEC file. No build dependencies. Only runtime dependency is the dkms package, which is already provided by EPEL. Not sure if we should provide dkms too, might be good, but we can also just let users know to enable EPEL for this one package.

I am willing to perform maintenance of all ZFS packages on all architectures, given I get virtual/physical access to a machine with said architecture. I already have two AArch64 SBCs, thanks to RESF.

I see that this has the following advantages for everyone:

Rocky users don't need to switch to Ubuntu/Debian to use ZFS on their non-x86 hardware.
Rocky users don't need to compile the ZFS packages (except for the kernel module shipped as DKMS). Tiny quality of life improvement, one less paper cut.
ZFS developers get bug reports about x86-isms in their codebase, via us or directly from the users.
Our supporters like 45Drives, Jeff Geerling, and many others don't need to say "Sorry, you can't use Rocky for that (ZFS)."

Let met start with **I am not a lawyer**. ZFS' CDDL license forbids from anyone distributing ZFS kernel module as a binary. The workaround to this is distributing ZFS kernel-space code as DKMS and user-space utilities as compiled binaries. Almost everyone other than Ubuntu does this. One of Oracle's representative did say that shipping compiled kernel modules is okay because "We didn't sue Canonical for this." Reference: [RHEL Panel Discussion at FOSSY 2023](https://sfconservancy.org/blog/2023/jul/19/rhel-panel-fossy-2023/), at timestamp `37:30`. And the OpenZFS developers already do that for `el8` and `el9`. But that's done only for x86_64. As a result, folks that want to use ZFS with Rocky Linux, on architectures like AArch64, need to [switch to Ubuntu/Debian](https://www.youtube.com/watch?v=iD9awxmOGG4&t=542s). I'd like if we did something to tackle this and documented it. I'd also like to inform our sponsors like 45Drives about it so they can also update their documentation likewise. A few days ago, when I watched the linked video, I created a COPR repository for ZFS and built packages, installed on my Rock 5B and ran the included ZFS test (part of the `zfs-test` package). And, the test passed. The SPEC files are already available in the [ZFS](https://github.com/OpenZFS/ZFS) repository, inside the `rpm/redhat` directory as `.spec.ac` files. All we need to do is replace strings `@[A-Z]+@` with appropriate values and voila, we have a usable SPEC file. No build dependencies. Only runtime dependency is the `dkms` package, which is already provided by EPEL. Not sure if we should provide `dkms` too, might be good, but we can also just let users know to enable EPEL for this one package. I am willing to perform maintenance of all ZFS packages on all architectures, given I get virtual/physical access to a machine with said architecture. I already have two AArch64 SBCs, thanks to RESF. I see that this has the following advantages for everyone: 1. Rocky users don't need to switch to Ubuntu/Debian to use ZFS on their non-x86 hardware. 2. Rocky users don't need to compile the ZFS packages (except for the kernel module shipped as DKMS). Tiny quality of life improvement, **one less paper cut**. 3. ZFS developers get bug reports about x86-isms in their codebase, via us or directly from the users. 4. Our supporters like 45Drives, Jeff Geerling, and many others don't need to say "Sorry, you can't use Rocky for that (ZFS)."

Sign in to join this conversation.