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

Thu May 20 18:33:31 UTC 2021
Neal Gompa <ngompa13 at gmail.com>

On Thu, May 20, 2021 at 2:30 PM Peter Georg
<peter.georg at physik.uni-regensburg.de> wrote:
>
> 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?
>

Yes.


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