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

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

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.

I think in the Wiki it is somewhere written that everything must be 
compatible with a "FOSS license". I can use the same wording here, 
despite not knowing in detail what qualifies a license as "FOSS".

But I'm not a lawyer, so in case there is someone with better knowledge 
about such licensing issues: Your help is highly appreciated!


> 
>> == Roadmap ==
>>    * Provide packages for in-kernel modules with restored support for
>> deprecated devices
>>    * Provide packages for in-kernel modules that have been supported
>> in
>> older CentOS major releases
>>    * Provide packages for further beneficial kernel modules requested
>> by
>> the community
>>
> 
> I'd add to the roadmap, establish a strong dialog with our friends at
> ELRepo.  In a perfect world we can get all the Stream kmods and RHEL
> kmods built under one process so folks don't need to duplicate effort
> .... in practice..... the shorter lifecycle of stream is a bit of an
> adventure here.

I'll add it to the roadmap.

>> == Resources ==
>> TBD
>>
> 
>  From a security/assurance standpoint, the modules will need to be
> signed by a cert dedicated to this SIG stored on some sort of "hard
> token".  Probably one cert per "release" (Stream 8, Stream 9, EL8?,
> EL9?) so they age out over time.

I can add signing of the modules here (or to the roadmap?). However it 
is not 100% clear to me yet how this should be done. Hence my idea was 
to first get started without signing any modules and try to get involved 
in the process the Hyperscale SIG is currently going through trying to 
figure out how to sign a kernel built by a SIG. I assume/hope a similar 
approach can then be used to sign these modules.

>> == Communication ==
>> The SIG uses the
>> [[
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.centos.org_mailman_listinfo_centos-2Ddevel-257Ccentos-2Ddevel&d=DwICAg&c=gRgGjJ3BkIsb5y6s49QqsA&r=OAMtP0DWou0nlXG7Kmxo2enjXJfwb1DXS9fwcaESuTE&m=pGCREeRni9c5EX2L12UG18KzS_jp_PQxqbJohJOAHmI&s=-pg4gO5kTAO-Ea-4VEabqff7mW9kzyUSDdpIheUp8N0&e=
>>   ]]
>> mailing list for coordination and communication.
>>
>> TBD: Add note about regular meetings once established.
>>
>> == Membership ==
>> The current set of members is:
>>
>> ##begin-members
>>    * ...
>> ##end-members
>>
>> The SIG is co-chaired by ... and ....
>>
>> Everybody is welcome to join and contribute to the SIG. Membership
>> can
>> be requested by asking on the
>> [[
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.centos.org_mailman_listinfo_centos-2Ddevel-257Ccentos-2Ddevel&d=DwICAg&c=gRgGjJ3BkIsb5y6s49QqsA&r=OAMtP0DWou0nlXG7Kmxo2enjXJfwb1DXS9fwcaESuTE&m=pGCREeRni9c5EX2L12UG18KzS_jp_PQxqbJohJOAHmI&s=-pg4gO5kTAO-Ea-4VEabqff7mW9kzyUSDdpIheUp8N0&e=
>>   ]]
>> mailing list. Any current member can raise objections and request a
>> simple majority vote on membership applications. SIG members are
>> expected to actively contribute or otherwise remain engaged with the
>> six months of inactivity.
>>
>> The SIG is co-chaired by two equal chairpersons elected by SIG
>> members
>> for one year. Each chairperson is elected individually using a
>> plurality
>> vote.
>> _______________________________________________
>> CentOS-devel mailing list
>> CentOS-devel at centos.org
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.centos.org_mailman_listinfo_centos-2Ddevel&d=DwICAg&c=gRgGjJ3BkIsb5y6s49QqsA&r=OAMtP0DWou0nlXG7Kmxo2enjXJfwb1DXS9fwcaESuTE&m=pGCREeRni9c5EX2L12UG18KzS_jp_PQxqbJohJOAHmI&s=9iDgov7u19oe2-1Q3j1rQKiAGjWU8eM2lp-FjgY-5bc&e=
>>   
> 
> _______________________________________________
> CentOS-devel mailing list
> CentOS-devel at centos.org
> https://lists.centos.org/mailman/listinfo/centos-devel
>