4 ms·
The end result is still positive. Before the mainline submission, Bcachefs could not be DKMSed, as it relied on changes in other subsystems, as opposed to just
by patrakov 1y ago
The end result is still positive. Before the mainline submission, Bcachefs could not be DKMSed, as it relied on changes in other subsystems, as opposed to just additions, so you had to compile your own kernel. Now, it is available as something that can be compiled as a module for any recent-enough third-party kernel.
- kouteiheika 1y ago...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 agoIt 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 agoThat'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 agodoes 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 agoQuite 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 agoNot 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 agoDoing "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 agoSun 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 agoIf 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).
- AndrewDavis 1y agoThat'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 agoThey 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 agoYou 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 agoCDDL 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 agoI 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.
- aragilar 1y agoBut presumably if said changes preventing DKMS usage were reasonable they would have been merged anyway independent of bcachefs, and likely with less drama and disruption? I'm not suggesting that there aren't some silver linings to the cloud, but it doesn't seem like the result is anywhere near neutral (let alone positive) for anyone involved.
- deleted 1y ago[deleted]
- arghwhat 1y agoYes and no - the kernel interfaces only reflect what the kernel itself needs. It doesn't to my knowledge maintain interfaces for the purpose of enabling out-of-tree modules. Changes would therefore need to be an improvement for in-tree drivers, and not merely something for an out-of-tree driver.
- dev_l1x_be 1y agoWas this the reason they removed it from mainline?
- masklinn 1y agoNo, the reason they removed it from mainline is that the maintainer has proved (yet again) incapable of working with others if they can't get their way: https://lore.kernel.org/all/CAHk-=wi+k8E4kWR8c-nREP0+EA4D+=rz5j0Hdk3N6cWgfE03-Q@mail.gmail.com/ https://lore.kernel.org/all/CAHk-=wi+k8E4kWR8c-nREP0+EA4D+=r...
- odo1242 1y agoNo, it was a conflict between Kent Overstreet and Linus Torvalds over Kent Overstreet constantly submitting patches too late in the merge window.
- charcircuit 1y agoSubmitting bug fixes for release candidates is not too late in the merge window. That's why they are a release candidate and not the final release.