CentOS Kmods SIG Working On exFAT, WireGuard Additions

[phoronix]

Phoronix: CentOS Kmods SIG Working On exFAT, WireGuard Additions

Created this year has been the CentOS Kmods special interest group for dealing with deprecated device support and out-of-tree modules. This Kmods SIG has begun crafting their initial set of extra kernel modules for use on CentOS...

https://www.phoronix.com/scan.php?page=news_item&px=CentOS-Kmods-exFAT-WG

[Peter_J_Georg]

Concerning filesystems ntfs3 is next on the list. It will be available in testing shortly after kernel 5.15 has been released.

In case anyone is interested in further information, there'll be a talk by the Kmods SIG on Friday. See the CentOS October Dojo timetable here: https://wiki.centos.org/Events/Dojo/October2021

[Developer12]

It'd be really nice if they could restore support for older SAS HBA cards. https://access.redhat.com/discussions/3722151

Beyond that I'd like it if they eventually supported ZFS as an out-of-tree module, similar to Ubuntu. That was the deciding factor between Cent and Ubuntu Server. For all the dumb bullshit I've had to put up with when using Ubuntu's half-baked server OS, I've never had to worry about the ZFS module and the kernel falling out of sync.

Canonical did the risky job of putting their toe in the water for them. I really don't see why they can't package up a ZFS module the same as an Nvidia one. They ship that. They could even use DKMS if they want. I don't care how they do it so long as it doesn't cause breakage.

And of course there's the ultimate prize: if Oracle started shipping RHEL's packaging of OpenZFS in their Oracle Unbreakable Linux RHEL downstream that would put all of these legal liability questions to bed once and for all.

[FireBurn]

exFat and Wireguard are neither out of tree or deprecated hardware support...

[Peter_J_Georg]

It'd be really nice if they could restore support for older SAS HBA cards. [url]https://access.redhat.com/discussions/3722151[/url

Support for some older SAS HBA cards has already been restored.
In the link you posted LSI SAS2008/2108/2116 are listed. Afaik these are support by the mpt3sas kernel module.
A rebuild of this kernel module with support restored for these deprecated adapters is already available in testing. E.g. see https://cbs.centos.org/koji/packageinfo?packageID=8520


About ZFS: License is the main issue here. Hence low priority.

[mskarbek]

Beyond that I'd like it if they eventually supported ZFS as an out-of-tree module, similar to Ubuntu. That was the deciding factor between Cent and Ubuntu Server. For all the dumb bullshit I've had to put up with when using Ubuntu's half-baked server OS, I've never had to worry about the ZFS module and the kernel falling out of sync.

Neither OpenZFS nor ZFS will ever be a part of that repository. Keeping OpenZFS komd and RHEL kernel in sync is fairly easy task considering kABI builds.

And of course there's the ultimate prize: if Oracle started shipping RHEL's packaging of OpenZFS in their Oracle Unbreakable Linux RHEL downstream that would put all of these legal liability questions to bed once and for all.

Oracle first would have to relicense their ZFS implementation, based on that OpenZFS would have to relicense, and then we would have a problem of incompatible disk format and Oracle pushing their implementation as a valid one although OpenZFS advanced much more. Oracle is not interested in shipping ZFS in UEK.

[RahulSundaram]

exFat and Wireguard are neither out of tree or deprecated hardware support...

They are out of tree for the kernel version that RHEL has for 10+ years.

[Developer12]

Neither OpenZFS nor ZFS will ever be a part of that repository. Keeping OpenZFS komd and RHEL kernel in sync is fairly easy task considering kABI builds.


Oracle first would have to relicense their ZFS implementation, based on that OpenZFS would have to relicense, and then we would have a problem of incompatible disk format and Oracle pushing their implementation as a valid one although OpenZFS advanced much more. Oracle is not interested in shipping ZFS in UEK.

The'd be interested if it became a useful and common addition to RHEL systems.

All of the licencing BS is likely overblown. Nvidia doesn't have to re-licence their kernel module to ship it and it's an GPL unfriendly as is physically possible. Even then, Ubuntu's legal analysis concluded that a compiled module is just fine, so long as it's not bundled in the same package with the kernel. So far that's worked out just fine for them.

You shouldn't believe everything the SFC says. They still tell everyone that kernel modules are universally a derived work of the kernel, when the kernel community (Linus) has explicitly said otherwise from the start.

[Developer12]

Neither OpenZFS nor ZFS will ever be a part of that repository. Keeping OpenZFS komd and RHEL kernel in sync is fairly easy task considering kABI builds.


Oracle first would have to relicense their ZFS implementation, based on that OpenZFS would have to relicense, and then we would have a problem of incompatible disk format and Oracle pushing their implementation as a valid one although OpenZFS advanced much more. Oracle is not interested in shipping ZFS in UEK.

They'd be interested if it was a common and useful part of RHEL systems. On-disk format isn't even a problem. They're two different filesystems at this point. Any sysadmin who tries to mount one with the other should be fired.

There's no need for re-licencing. The SFC might tell you otherwise, but they'll also tell you (and their ZFS argument hinges on) that all kernel modules are unavoidably a derived work of the kernel. Nvidia certainly isn't troubled by that and everyone ships their modules. Ubuntu's legal analysis also determined that a compiled kernel module is just fine, so long as it's not bundled in the same package as the kernel during distribution. So far things have worked out just fine for them, with not a single challenge for years.

[FireBurn]

They are out of tree for the kernel version that RHEL has for 10+ years.

That's backporting, not out of tree