4 ms·

The slight benefit for out-of-tree module authors wouldn't be worth the negative effects on the rest of the kernel to everyone else.

charcircuit 1y ago
"slight benefit"? Having a working system after upgrading your kernel is not just a slight benefit. It's table stakes. Especially for something critical like a filesystem it should never break. >negative effects on the rest of the kernel Needing to design and support an API is not purely negative for kernel developers. It also gives a change to have a proper interface for drivers to use and follow. Take a look at the Rust for Linux which keeps running into undocumented APIs that make little sense and are just whatever <insert most popular driver> does.
- josephcsible 1y ago
  > Having a working system after upgrading your kernel is not just a slight benefit. It's table stakes. We already have that, with the "don't break userspace" policy combined with all of the modules being in-tree. > Needing to design and support an API is not purely negative for kernel developers. Sure, it's not purely negative, but it's overall a big net negative. > Take a look at the Rust for Linux which keeps running into undocumented APIs that make little sense and are just whatever <insert most popular driver> does. That's an argument against a stable module API! Those things are getting fixed as they get found, but if we had a stable module API, we'd be stuck with them forever. I recommend reading https://docs.kernel.org/process/stable-api-nonsense.html https://docs.kernel.org/process/stable-api-nonsense.html
  - charcircuit 1y ago
    >We already have that, with the "don't break userspace" Bcachefs is not user space. >with all of the modules being in-tree. That is not true. There are out of tree modules such as ZFS. >That's an argument against a stable module API! My point was that there was 0 thought put into creating a good API. Additionally API could be evolved over time and have a support period if you care about being able to evolve it and deprecate the old one. And likely even with a better interface there is probably a way to make the old API still function.
    - josephcsible 1y ago
      > Bcachefs is not user space. bcachefs is still in-tree. > That is not true. There are out of tree modules such as ZFS. ZFS could be in-tree in no time at all if Oracle would fix its license. And until they do that, it's not safe to use ZFS-on-Linux anyway, since Oracle could sue you for it. > My point was that there was 0 thought put into creating a good API. There is thought put into it: it's exactly what we need right now, because if what we need ever changes, we'll change the API too, thus avoiding YAGNI and similar problems. > Additionally API could be evolved over time and have a support period if you care about being able to evolve it. If a temporary "support period" is what you want, then just use the LTS kernels. That's already exactly what they give you. > And likely even with a better interface there is probably a way to make the old API still function. That's the big net negative I was mentioning and that https://docs.kernel.org/process/stable-api-nonsense.html https://docs.kernel.org/process/stable-api-nonsense.html talks about too. Sometimes there isn't a feasible way to support part of an old API anymore, and it's not worth holding the whole kernel back just for the out-of-tree modules.
      - deleted 1y ago
        [deleted]
      - yjftsjthsd-h 1y ago
        > ZFS could be in-tree in no time at all if Oracle would fix its license. And until they do that, it's not safe to use ZFS-on-Linux anyway, since Oracle could sue you for it. IANAL, but I don't believe either of these things are true. OpenZFS contains enough code not authored by Sun/Oracle that relicensing it now is effectively impossible. OTOH, it is under the CDDL, which is a perfectly good open source license; AFAICT the problem, if one exists at all[0], only manifests when distributing the combination of CDDL (OpenZFS) and GPL (Linux) software. If you download CDDL software and compile it into GPL software yourself (say, with DKMS) then it should be fine because you aren't distributing it. [0] This is a case where I'm going to really emphasize that I'm really not a lawyer and merely point out that ex. Canonical's lawyers do seem to think CDDL+GPL is okay.
        1y ago
- msgodel 1y ago
  Does your system have some critical out of tree driver? That should have been recompiled with the new kernel, that sounds like a failure of whoever maintains the driver/kernel/distro (which may be you if you're building it yourself.)

charcircuit 1y ago

"slight benefit"? Having a working system after upgrading your kernel is not just a slight benefit. It's table stakes. Especially for something critical like a filesystem it should never break. >negative effects on the rest of the kernel Needing to design and support an API is not purely negative for kernel developers. It also gives a change to have a proper interface for drivers to use and follow. Take a look at the Rust for Linux which keeps running into undocumented APIs that make little sense and are just whatever <insert most popular driver> does.

josephcsible 1y ago
> Having a working system after upgrading your kernel is not just a slight benefit. It's table stakes. We already have that, with the "don't break userspace" policy combined with all of the modules being in-tree. > Needing to design and support an API is not purely negative for kernel developers. Sure, it's not purely negative, but it's overall a big net negative. > Take a look at the Rust for Linux which keeps running into undocumented APIs that make little sense and are just whatever <insert most popular driver> does. That's an argument against a stable module API! Those things are getting fixed as they get found, but if we had a stable module API, we'd be stuck with them forever. I recommend reading https://docs.kernel.org/process/stable-api-nonsense.html https://docs.kernel.org/process/stable-api-nonsense.html
- charcircuit 1y ago
  >We already have that, with the "don't break userspace" Bcachefs is not user space. >with all of the modules being in-tree. That is not true. There are out of tree modules such as ZFS. >That's an argument against a stable module API! My point was that there was 0 thought put into creating a good API. Additionally API could be evolved over time and have a support period if you care about being able to evolve it and deprecate the old one. And likely even with a better interface there is probably a way to make the old API still function.
  - josephcsible 1y ago
    > Bcachefs is not user space. bcachefs is still in-tree. > That is not true. There are out of tree modules such as ZFS. ZFS could be in-tree in no time at all if Oracle would fix its license. And until they do that, it's not safe to use ZFS-on-Linux anyway, since Oracle could sue you for it. > My point was that there was 0 thought put into creating a good API. There is thought put into it: it's exactly what we need right now, because if what we need ever changes, we'll change the API too, thus avoiding YAGNI and similar problems. > Additionally API could be evolved over time and have a support period if you care about being able to evolve it. If a temporary "support period" is what you want, then just use the LTS kernels. That's already exactly what they give you. > And likely even with a better interface there is probably a way to make the old API still function. That's the big net negative I was mentioning and that https://docs.kernel.org/process/stable-api-nonsense.html https://docs.kernel.org/process/stable-api-nonsense.html talks about too. Sometimes there isn't a feasible way to support part of an old API anymore, and it's not worth holding the whole kernel back just for the out-of-tree modules.
    - deleted 1y ago
      [deleted]
    - yjftsjthsd-h 1y ago
      > ZFS could be in-tree in no time at all if Oracle would fix its license. And until they do that, it's not safe to use ZFS-on-Linux anyway, since Oracle could sue you for it. IANAL, but I don't believe either of these things are true. OpenZFS contains enough code not authored by Sun/Oracle that relicensing it now is effectively impossible. OTOH, it is under the CDDL, which is a perfectly good open source license; AFAICT the problem, if one exists at all[0], only manifests when distributing the combination of CDDL (OpenZFS) and GPL (Linux) software. If you download CDDL software and compile it into GPL software yourself (say, with DKMS) then it should be fine because you aren't distributing it. [0] This is a case where I'm going to really emphasize that I'm really not a lawyer and merely point out that ex. Canonical's lawyers do seem to think CDDL+GPL is okay.
      - 1y ago
msgodel 1y ago
Does your system have some critical out of tree driver? That should have been recompiled with the new kernel, that sounds like a failure of whoever maintains the driver/kernel/distro (which may be you if you're building it yourself.)