On 28.05.19 18:43, Dan wrote: > Sadly the Linux Kernel has introduced a commit in kernel 4.19 and 5.0> that > prevents ZFS from using SIMD. The result is that ZFS won't be> usable in Buster. See the following issue> https://github.com/zfsonlinux/zfs/issues/8793 We recently had this discussion on lkml - yet another case of 3rdparty folks that just don't follow the license rules.
It's not the kernel who broke zfs, it's zfs that broke itself. The kernel is GPL, and they just have to follow the rules or go away. OOT modules are conceptionally messy in the first place. It's sometimes okay as an temporary workaround, until things get mainlined. But intentionally keeping things oot for long time is just silly and creates lots of more problems than it creates. And they're even using now *deeply* arch-internal functions directly. > NixOS reverted that particular commit:> https://www.phoronix.com/scan.php?page=news_item&px=NixOS-Linux-5.0-ZFS-FPU-Drop Intentional license violation. Not funny. > Debian is the "Universal Operating System" and gives the user the> option to > choose. It provides "vim and emacs", "Gnome and KDE", If you wanna have something new included, you'll have to sit down and do the actual work. In the end of the day, it's that simple. > Would it be possible to provide an alternative patched linux kernel > that works with ZFS? You mean patching against the license ? > The ZFS developers proposed the Linux developers to rewrite the whole > ZFS code and use GPL, but surprisingly the linux developers didn't > accept. See below: > https://github.com/zfsonlinux/zfs/issues/8314 Wait, no. It's not that we refused anything (actually, I don't even recall any decent discussion on that @lkml). There even wasn't anything to accept or refuse - except the existing code, that is nowhere near a quality where any maintainer likes to even have a closer look at. The major problem is that ZoL always has been oot on purpose, which is the wrong approach to begin with. That also leads to bad code quality (eg. lots of useless wrappers, horrible maintenance, ...) What ZoL folks could do is step by step rewrite it to use mainline functionality where ever technically feasible and work closely with upstream to introduce missing functionality. Obviously, their current proprietary userland interface can't be accepted for mainline - it has to be reworked to be conformant w/ standard uapi (eg. we already have it for things like snapshots, deduplication, quotas, ...) But it's up to ZoL developers to do the actual work and post patches to lkml. There won't be anybody else doing that. --mtx -- Enrico Weigelt, metux IT consult Free software and Linux embedded engineering i...@metux.net -- +49-151-27565287
