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

Neal Gompa

ngompa13 at gmail.com
Thu May 20 18:11:18 UTC 2021


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.

Nvidia is more obviously not allowed as proprietary software.



-- 
真実はいつも一つ!/ Always, there's only one truth!


More information about the CentOS-devel mailing list