If Linux would add a stable kernel module API this wouldn't be a huge a problem and it would be easy for bcachefs to ship as a kernel module with his own independent release schedule.
replies(4):
>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.
>FreeBSD (which is often invoked in these complaints) would have amdgpu for example.
In such a hypothetical FreeBSD could reimplement the stable API of Linux.
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
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.
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 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.
Like it does with the userland API of Linux, which is stable:
I worked for HP on storage drivers for a decade or so, and had their been a stable ABI, HP would have shipped proprietary storage drivers for everything. Even without a stable ABI, they shipped proprietary drivers at considerable effort, compiling for myriad different distro kernels. It was a nightmare, and good thing too, or there wouldn't be any open source drivers.
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.
Which excludes a vast amount of activity one might want to use Linux for which is otherwise allowed. Like selling a device with a Linux installation, distributing VM or system restore images, etc.
(it's not obvious that having to occasionally disassemble/patch closed-source drivers is worse than the collective effort wasted trying to get every single thing in the kernel and keep it up to date).
It's not against the license to use them together.
>If a temporary "support period" is what you want, then just use the LTS kernels. That's already exactly what they give you.
Only the Android one does. The regular LTS one has no such guarantee.
This is clearly untrue. Upon what theory?
An unstable interface means the driver source needs to be updated frequently, you can't just dump a .ko file online and expect it to work for however long the hardware lasts.
Easiest way to approach it is to attempt to upstream drivers, and potentially take advantage of free labor and maintenance in virtual perpetuity, which is good for all Linux users. If vendors don't want to spend the effort upstreaming drivers, but they need to support Linux, by necessity the drivers must be open source so they can be compiled against users' changing kernels. That's at least a step in the right direction, and should anyone want to make the effort, they're free to upstream drivers themselves.
I don't think so. Suppose Oracle did agree to put their code under GPLv2/CDDL dual licensing.
Then, I'm sure if you look at the non-Oracle contributors to OpenZFS, there's a few big ones and a long tail of smaller ones. Many of the big ones might be able and willing to follow Oracle's lead. Chasing down the smaller ones may be harder, but it is possible their contributions may be judged as sufficiently trivial to escape copyright protection. More substantive contributions from people who are unreachable (or unwilling/unable to consent to the relicensing) can pose a bigger issue, but it could be solved either by (a) intentionally rewriting their contributions from scratch; (b) given enough time, decent chance (a) will happen anyway just to normal code churn, even if you don't do it intentionally for licensing reasons.
It would be a big, multi-year project, but one that other open source communities have successfully tackled, most notably LLVM – so I do think "effectively impossible" is too strong.
I think the biggest blocker is that, it is hard to motivate people to make the effort unless Oracle is on-board – and they've displayed no signs of willingness to change their position on this. I doubt Oracle will budge, but anything is possible.
Another possibility to consider – CDDL clause 4 allows the "license steward" (Sun Microsystems) [0] to release a new version, which automatically applies to all CDDL software unless the developers explicitly opt-out. I don't know if any of the OpenZFS developers have made such an explicit opt-out – but if they haven't, then Oracle could issue a new CDDL version adding a clause saying that if the covered work is ZFS or a derivative thereof, anyone is allowed to relicense it under GPLv2. Then you wouldn't even need to track down and get the consent of non-Oracle contributors. For a real historical example of something like this, witness how the FSF issued a new GFDL version just to help Wikipedia move from GFDL to Creative Commons licensing. But, again, even if this is legally possible, unlikely (but not impossible) Oracle will ever cooperate in it.
Another blocker is that even if OpenZFS were relicensed as GPLv2/CDDL, that still wouldn't solve the issue that Torvalds is unlikely to agree to upstreaming it as part of the mainline Linux kernel – a massive code base written in a very different style, and having portability concerns (wanting to work on BSD/etc too) which Linux normally doesn't care about. Possibly if you forked OpenZFS, ripped out the cross-platform aspects, and rewrote it to be more like typical Linux kernel code, it might have a chance. But, will anyone be willing to make that massive investment of time and effort? And even assuming they succeeded, we'd now have two forks of ZFS (one in the Linux kernel, one for other operating systems), adding to the maintenance burden, and the risk they'd diverge over time would be high.
[0] Sun Microsystems still legally exists on paper, and probably will indefinitely, as an Oracle subsidiary – it has been renamed to Oracle America Inc – so Oracle has effectively inherited Sun's rights as CDDL license steward
So don't repeat these legends from 20 years ago. However, this may not have been true even 20 years ago.
Yes, bad driver implementations that shit all over the kernel tree just to get hardware "working" should not be upstreamed. 99% of the time in these cases, Chinese equipment manufacturers can't be bothered to write acceptable code and it's a good thing it isn't mainlined and made someone else's problem.