[CentOS-devel] [EXT] Re: RFC: kmods SIG Proposal

Thu May 20 18:30:14 UTC 2021
Peter Georg <peter.georg at physik.uni-regensburg.de>

On 20/05/2021 20.11, Neal Gompa wrote:
> On Thu, May 20, 2021 at 2:08 PM Peter Georg
> <peter.georg at physik.uni-regensburg.de> wrote:
>> On 20/05/2021 17.22, Patrick Riehecky wrote:
>>> Adding notes in line below:
>>> On Wed, 2021-05-19 at 17:56 +0200, Peter Georg wrote:
>>>> Dear all,
>>>> I'd like to propose a SIG for CentOS Stream. Please see the proposal
>>>> below.
>>>> Note: In case anyone has a better suggestion for a name, please let
>>>> me
>>>> know. I'm really terrible at naming things. And sorry in advance for
>>>> any
>>>> spelling or grammar mistakes (I'm not a native english speaker).
>>>> For everyone following the previously posted "RFC: Stream Kernel SIG
>>>> Proposal": The goal of the "kmods" SIG proposed here has previously
>>>> been
>>>> proposed to be added to a potential "Stream Kernel SIG" as a fifth
>>>> goal.
>>>> However it seems to make sense to split the various different goals
>>>> into
>>>> seperate SIGs.
>>>> Disclaimer: I used the Hyperscale SIG description
>>>> (
>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.centos.org_SpecialInterestGroup_Hyperscale&d=DwICAg&c=gRgGjJ3BkIsb5y6s49QqsA&r=OAMtP0DWou0nlXG7Kmxo2enjXJfwb1DXS9fwcaESuTE&m=pGCREeRni9c5EX2L12UG18KzS_jp_PQxqbJohJOAHmI&s=Y8Rc2wfIQTiG6pW9V55QTQmMkjJEFYkhtAZdWRjBXlA&e=
>>>>    ) as a template.
>>>> I hope that's OK.
>>> The more we can reuse things that work and make a cleaner/better/easier
>>> process the happier we will all be :)
>>>> Best,
>>>> Peter
>>>> Proposal:
>>>> = kmods SIG =
>>>> == Goals ==
>>>> The kmods SIG will focus on providing kernel modules currently not
>>>> available in CentOS Stream.
>>>> == Status ==
>>>> Proposed: RFC and looking for a sponsoring Governing Board member
>>> As a board member I hereby indicate a willingness to sponsor.  If
>>> another board member is passionate about this, I'll be happy to hand it
>>> over to them.  I've regularly made use of external kmods (for old
>>> hardware and proprietary hardware)and would strongly like to see them
>>> continue in Stream!
>>>> == What's in scope ==
>>>> This SIG is a good place for any kernel module that is beneficial to
>>>> CentOS Stream, but cannot be directly contributed to any of the
>>>> involved
>>>> upstream projects. These kernel modules may be divided in three
>>>> categories:
>>>> === Restore support for deprecated devices ===
>>>> The CentOS Stream kernel includes several kernel modules for which
>>>> the
>>>> list of supported devices has been limited by Red Hat. This SIG aims
>>>> to
>>>> many deprecated and removed devices as possible.
>>>> A close collaboration with the kernel-plus developers is desired for
>>>> these kernel modules.
>>>> === In-kernel modules not enabled for CentOS Stream ===
>>>> Many in-kernel modules are simply disabled for the CentOS Stream
>>>> kernel.
>>>> This may either be due to  drivers being deprecated and removed
>>>> compared
>>>> to older CentOS major releases or never being enabled in the first
>>>> place. This SIG aims to provide these in-kernel drivers as external
>>>> kernel modules to enable CentOS Stream running on a broader range of
>>>> available hardware and provide other beneficial functionality.
>>>> A close collaboration with the kernel-plus developers is desired for
>>>> these kernel modules. In addition it is desired to work with upstream
>>>> to
>>>> get any valuable kernel modules directly into the CentOS Stream
>>>> kernel.
>>>> === Third-party external kernel modules ===
>>>> This SIG also aims to provide third-party kernel modules for CentOS
>>>> Stream not (yet) available in upstream kernel.
>>>> == What's not in scope ==
>>>> Anything that can be contributed directly to any of the involved
>>>> upstream projects is not in scope. This includes, but is not limited
>>>> to:
>>>> * New user space packages: These should be submitted to Fedora/EPEL
>>>> * Support for new architectures currently not supported by CentOS
>>>> Stream
>>>> * Third-party kernel modules with non compatible license
>>> Echoing other thoughts, packages in EPEL should be installable by folks
>>> with or without the SIG.  So I'd suggest anything that isn't dependent
>>> on the kmods, should go into EPEL, but things that are kmod specific
>>> should probably stay within the SIG.  In theory, if userspace is tied
>>> to the kmod, synchronizing updates would be cleaner if things were in
>>> just the one place.
>> Makes sense. I'll wait for further input on this point and will then try
>> to come up with a better solution.
>>> I'm a bit concerned that "non compatible license" is a bit vague.
>>> Would this exclude DRBD, ZFS on Linux, OpenAFS, or nVidia?  The nVidia
>>> bits seem to be 'yes, it is excluded', I'm less sure on the other two.
>> Concerning your examples: Afaik the CDDL (ZFS) is considered a free
>> software license by the FSF. So I assume this should be fine.
>> The nVidia bits are probably not allowed.
> OpenZFS has not been allowed per Red Hat Legal, so I don't think you
> can do that.

Well, as I said: I'm not a lawyer :)
But good to know, thanks!

Does this mean that legally the same restrictions that apply to getting 
a package into RHEL also apply to packages provided by a CentOS SIG?

> Nvidia is more obviously not allowed as proprietary software.