6 ms·

...for now. The policy of Linux is that they don't care about external modules/drivers at all, so once they start removing whatever bcachefs needs because no in

...for now. The policy of Linux is that they don't care about external modules/drivers at all, so once they start removing whatever bcachefs needs because no in-tree filesystem uses it we'll be back to a world of pain. (Unless they make an exception; they sure don't make one for ZFS.)

ThatPlayer 1y ago
It doesn't seem to have been completely removed: Bcachefs is still listed among the MAINTAINERS: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/diff/MAINTAINERS?id=f2c61db29f27 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin... where only the references to removed files were removed. For now
alphabetag675 1y ago
That's patently untrue. They do not remove stuff, they just keep changing the APi which means that the modules need to keep evolving.
- matja 1y ago
  does removing EXPORT_SYMBOL(__kernel_fpu_end); [0] - which broke ZFS, count as removing stuff or changing the API? AFAIK that change didn't add functionality or fix any existing issues, other than breaking ZFS - which GKH was absolutely fine with, dismissing several requests for it to be reverted, stating the "policy": [1] > Sorry, no, we do not keep symbols exported for no in-kernel users. [0] https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=v6.16.9&id=12209993e98c5fa1855c467f22a24e3d5b8be205 https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux... [1] https://lore.kernel.org/lkml/20190111054058.GA27966@kroah.com/ https://lore.kernel.org/lkml/20190111054058.GA27966@kroah.co...
  - mnau 1y ago
    Quite reasonable policy. Add a second line too: > Sun explicitly did not want their code to work on Linux, so why would we do extra work to get their code to work properly? Why would you accommodate someone who explicitly went out of their way to not accommodate you? It took many conflicts with bcachefs developer to reach this state. Olive branch has been extended again and again...
    - timeon 1y ago
      Not sure if the thread is about how reasonable is the policy or if it is patently untrue that things get removed.
    - matja 1y ago
      "accommodate" in this instance would have been accomplished by doing nothing. The Linux kernel developers actively made this change.
      - mnau 1y ago
        Doing "nothing" in this case seems to be leaving technical debt in a code. I am not kernel developer, but less exposed API/functions is nearly always better. The removed comment of function even starts with: Careful: __kernel_fpu_begin/end() must be called with
    - nubinetwork 1y ago
      Sun doesn't exist anymore, and while openzfs is compatible with older versions of any of Oracle's life support Solaris, it's not the same ecosystem. Yes, the same licensing issues still exist, but openzfs has been developed by LLNL for Linux ever since it was called "zfs for Linux".
      - capitol_ 1y ago
        If that ecosystem have changed their values/opinions on that topic, the it wouldn't be an impossible task to dual-license it with a compatible license. (Hard and tedious work, but not impossible).
        SXX 1y ago
        The only entity that can change of ZFS license is Oracle and they obviously wouldnt do that.
        bluGill 1y ago
  - darthcloud 1y ago
    I was curious how OpenZFS worked around that and found [0] & [1] [0] https://github.com/openzfs/zfs/issues/8259 https://github.com/openzfs/zfs/issues/8259 [1] https://github.com/openzfs/zfs/pull/8965 https://github.com/openzfs/zfs/pull/8965
- AndrewDavis 1y ago
  That's all a matter of perspective. Is moving a symbol from EXPORT_SYMBOL(some_fun) to EXPORT_SYMBOL_GPL(some_func) actually changing the API? Nope, the API is exactly the same as it was before, it's just changed who is allowed to use it. From the perspective of an out of tree module that isn't GPL you have removed stuff. I'm honestly not sure how one outside the kernel community could construe that as not removing something.
  - happymellon 1y ago
    They could always move to a compatible license? No, it was always designed to be hostile to Linux from the outset. It's a project that doesn't want to interoperability with Linux so I'm not entirely sure why you think the Linux folks should maintain an API for them.
    - Sanzig 1y ago
      You are ascribing motives to the OpenZFS project that aren't there. Sun was the one that licensed it CDDL, and OpenZFS is a fork that was created when Oracle bought Sun and decided to close source ZFS. Oracle has zero involvement with OpenZFS. Since the pre-fork code is from Sun, Oracle owns the copyright, and they won't re-license it. The idea that the OpenZFS team wants CDDL out of spite for Linux is an absurd conspiracy theory. Their hands are tied - I'm sure they'd move to a compatible license if they could, but they can't.
      - p_l 1y ago
        CDDL ensures OpenZFS can be used for not just Linux, and prevents patent-based attacks (which have been used against GPLv2 code reuse in the past). So the OpenZFS team is not exactly interested in moving to GPLv2, because it would break multiple platforms.
        Sanzig 1y ago
        I doubt the OpenZFS team would move to GPLv2 if they were able to relicense to anything they wanted. Given their close association with FreeBSD, BSD-2 or a similar permissive license wouldn't shock me. But it's an academic exercise anyway, since it seems Oracle has no intention of allowing them to relicense.

ThatPlayer 1y ago

It doesn't seem to have been completely removed: Bcachefs is still listed among the MAINTAINERS: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/diff/MAINTAINERS?id=f2c61db29f27 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin... where only the references to removed files were removed. For now

alphabetag675 1y ago

That's patently untrue. They do not remove stuff, they just keep changing the APi which means that the modules need to keep evolving.

matja 1y ago
does removing EXPORT_SYMBOL(__kernel_fpu_end); [0] - which broke ZFS, count as removing stuff or changing the API? AFAIK that change didn't add functionality or fix any existing issues, other than breaking ZFS - which GKH was absolutely fine with, dismissing several requests for it to be reverted, stating the "policy": [1] > Sorry, no, we do not keep symbols exported for no in-kernel users. [0] https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=v6.16.9&id=12209993e98c5fa1855c467f22a24e3d5b8be205 https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux... [1] https://lore.kernel.org/lkml/20190111054058.GA27966@kroah.com/ https://lore.kernel.org/lkml/20190111054058.GA27966@kroah.co...
- mnau 1y ago
  Quite reasonable policy. Add a second line too: > Sun explicitly did not want their code to work on Linux, so why would we do extra work to get their code to work properly? Why would you accommodate someone who explicitly went out of their way to not accommodate you? It took many conflicts with bcachefs developer to reach this state. Olive branch has been extended again and again...
  - timeon 1y ago
    Not sure if the thread is about how reasonable is the policy or if it is patently untrue that things get removed.
  - matja 1y ago
    "accommodate" in this instance would have been accomplished by doing nothing. The Linux kernel developers actively made this change.
    - mnau 1y ago
      Doing "nothing" in this case seems to be leaving technical debt in a code. I am not kernel developer, but less exposed API/functions is nearly always better. The removed comment of function even starts with: Careful: __kernel_fpu_begin/end() must be called with
  - nubinetwork 1y ago
    Sun doesn't exist anymore, and while openzfs is compatible with older versions of any of Oracle's life support Solaris, it's not the same ecosystem. Yes, the same licensing issues still exist, but openzfs has been developed by LLNL for Linux ever since it was called "zfs for Linux".
    - capitol_ 1y ago
      If that ecosystem have changed their values/opinions on that topic, the it wouldn't be an impossible task to dual-license it with a compatible license. (Hard and tedious work, but not impossible).
      - SXX 1y ago
        The only entity that can change of ZFS license is Oracle and they obviously wouldnt do that.
        bluGill 1y ago
- darthcloud 1y ago
  I was curious how OpenZFS worked around that and found [0] & [1] [0] https://github.com/openzfs/zfs/issues/8259 https://github.com/openzfs/zfs/issues/8259 [1] https://github.com/openzfs/zfs/pull/8965 https://github.com/openzfs/zfs/pull/8965
AndrewDavis 1y ago
That's all a matter of perspective. Is moving a symbol from EXPORT_SYMBOL(some_fun) to EXPORT_SYMBOL_GPL(some_func) actually changing the API? Nope, the API is exactly the same as it was before, it's just changed who is allowed to use it. From the perspective of an out of tree module that isn't GPL you have removed stuff. I'm honestly not sure how one outside the kernel community could construe that as not removing something.
- happymellon 1y ago
  They could always move to a compatible license? No, it was always designed to be hostile to Linux from the outset. It's a project that doesn't want to interoperability with Linux so I'm not entirely sure why you think the Linux folks should maintain an API for them.
  - Sanzig 1y ago
    You are ascribing motives to the OpenZFS project that aren't there. Sun was the one that licensed it CDDL, and OpenZFS is a fork that was created when Oracle bought Sun and decided to close source ZFS. Oracle has zero involvement with OpenZFS. Since the pre-fork code is from Sun, Oracle owns the copyright, and they won't re-license it. The idea that the OpenZFS team wants CDDL out of spite for Linux is an absurd conspiracy theory. Their hands are tied - I'm sure they'd move to a compatible license if they could, but they can't.
    - p_l 1y ago
      CDDL ensures OpenZFS can be used for not just Linux, and prevents patent-based attacks (which have been used against GPLv2 code reuse in the past). So the OpenZFS team is not exactly interested in moving to GPLv2, because it would break multiple platforms.
      - Sanzig 1y ago
        I doubt the OpenZFS team would move to GPLv2 if they were able to relicense to anything they wanted. Given their close association with FreeBSD, BSD-2 or a similar permissive license wouldn't shock me. But it's an academic exercise anyway, since it seems Oracle has no intention of allowing them to relicense.