oh - didn't know about the backport - considering the change in question is really just a few lines and more or less cosmetic it's a political move. This basically makes native ZFS encryption very slow on recent Linux kernels. Sad move.
Lost a lot of respect for the Linux devs due to this story - this is just stupid fuckery due to hurt egos or whatever. Droping that API in 5.0+ fine - but backporting the removal of the non-GPL API in -stable kernels?
What's childish about it? They refactored their code and removed a legacy header in the process. If ZFS was a part of the kernel it would have been fixed as a part of the refactoring.
What's going on here is that people on the internet are asking Greg K-H to do extra work and his reply is that he doesn't care to.
If anything what is childish is random internet users thinking that they are entitled to Linux dev's time and work.
> What's going on here is that people on the internet are asking Greg K-H to do extra work and his reply is that he doesn't care to.
That really isn't "what's going on here." The "extra work" is changing one or two lines from containing EXPORT_SYMBOL_GPL to EXPORT_SYMBOL and possibly moving them to a different place.
If you read through the email thread [1] linked in another comment, you'll see something completely different is being argued and discussed.
You can use FreeBSD, they are happy to provide their sources to proprietary projects. Linux uses different license and cares about projects that contribute back, nothing wrong with that.
I'm describing a retroactive change that has no technical justification, only political motivation. I have very liberal license preferences, but that move was beyond the pale: a big middle finger to a kernel module which is clearly not a derived work of the Linux kernel.
Engineering, technology, and science are deeply political, where politics isn't restricted to governments, parties, or official state systems. Refusal to recognize that doesn't change it.
The GPL is a licence that was created by people well-aware of the political significance, and it is the embodiment of certain political intentions in form of a licence. Projects that consciously use it can be expected to act upon those political intentions. Not understanding actions upon those political intentions is rather a sign of not understanding the situation.
It's certainly peculiar that the person driving efforts to cripple ZFS (which is, let us note, under an opensource license, albeit a GPL-hostile one) seems to be putting tremendous effort into doing it while being completely disinterested in, for example, the entirely proporietary graphics drivers from free software hostile companies such as NVidia.
Wait, that got backported to LTS kernels?! No wonder my performance testing shows no difference!!!
Though I could have sworn the controversy was about __kernel_fpu becoming kernel_fpu - is there another set of git commits I need to find and rollback/reverse engineer on my 4.19 branch?
If a patch for zfs shows up in some random github repo that correctly teaches it to use the gpl-only symbols? I hope it makes it into your hands.
It's not linux fundamentalism here - it backdates to Sun who released ZFS under a license that appears to be deliberately designed to make it incompatible with the GPL
According to their repo, it is still under CDDL, which is said license. That it is an open-source license doesn't mean it is compatible with GPL (if it is appears to still be a hotly debated topic, but the kernel devs have picked one stance)
As the other posters have pointed out - it's definitely an open source project with an open source license, but it's the CDDL. Same as it was in 05.
I love ZFS, use it on my server. It sucks that this has happened but AFAICT it's the result of a license choice made way back when, and it's still impacting things now.
There are competing file systems on Linux which are more aligned with Linux goals and much better integrated with kernel. If ZFS won't work very well on Linux, it gives more chances for those alternative file systems (btrfs, bcachefs), so hopefully one day they'll be proper replacements and ZFS won't be needed at all. This is political thing indeed.
Anyway you can always patch the kernel. It won't be as easy to install, but e.g. Ubuntu should be able to do so.
I remember reading about BTRFS parity patches that were shelved because they didn't align with someone's business interests. Maybe a storage vendor is exerting some pressure to impede modern file systems on Linux.
Does anyone know what the "real" reason is for not exporting the kernel function in 5.0+ anymore?
Is there a technical reason, additional work or is it just a middle finger to ZFS devs?
The functions/symbols being used were __kernel_fpu_{begin,end}. These were designed for use within the kernel, and not for external modules - however external modules used them since there was no other alternative. At some point the kernel announced these were being deprecated, and have now been removed.
Since they weren't designed for external modules, someone submitted a patch to make them exportable. However the patch enforced EXPORT_SYMBOL_GPL, so only modules that report being GPL licensed can use them.
Now ZFS is in a position where it can't use the original kernel symbols since they were removed, but can't use the new ones since they are marked as EXPORT_SYMBOL_GPL.
Thanks to the kind folks putting in the effort and bringing this to linux, every release excites me! I've been a long long time fan of ZFS on BSD and Solaris (yes I'm old).
Probably the most notable thing is compatibility with the upcoming 5.2 kernel, otherwise just minor bugfixes.
0.8.0 came out just a few weeks ago and was a pretty huge release. It added encryption, TRIM support for SSDs, ability to remove disks from zpools, performance improvements, and more.
For me it's notable that the first drop doesn't contain any "oh shit" bugs, which would tend to suggest the more conservative amongst us should be thinking about upgrading the on-disk format from 0.7.x to 0.8.x.
