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!