On 23/05/2021 21.00, Jeffrey E Altman wrote: > On 5/23/2021 10:32 AM, Peter Georg > (peter.georg at physik.uni-regensburg.de) wrote: >> Thanks to everyone for the input so far. I updated the original >> proposal to reflect your input. In case I forgot something, please let >> me know. > > This looks very good so far. One comment below: > >> === 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. >> >> === Third-party external kernel modules === > > Might I suggest "out-of-kernel modules" instead of "third-party external > kernel modules". I actually do prefer "out-of-tree kernel modules" over "out-of-kernel modules". "out-of-tree kernel modules" is probably a better description than "thrid-party external kernel modules". Hence I'm thinking about doing a s/thrid-party external/out-of-tree/g. But then I probably should also s/in-kernel/in-tree kernel/g. Opinions? Dicussing details like this, I think we are on a good way :) > >> This SIG also aims to provide third-party kernel modules for CentOS >> Stream not (yet) available in upstream kernel. > > The "not (yet)" makes me wonder what the criteria for inclusion are. Is > it a requirement that the module might be accepted into the upstream > kernel if submitted? If this is the intent, I believe that would > exclude two categories of modules. First, modules that provide > functionality already provided by an actively maintained in-kernel > module. Second, modules whose licenses are not listed in > include/linux/license.h. This was actually not the intention, but I totally understand why you think it has been. I currently don't see why we should restrict the SIG to modules that might be accepted into upstream kernel. The restriction to GPL v2 compatible licenses is there due to legal reasons. Is there any reason why we should restrict ourselves to kernel modules that might be accepted into upstream? > > Later on the "What's not in scope" section says: > > > * Third-party kernel modules with a non GPL v2 compatible license > which is overly broad. Might I suggest: > > [BEGIN] > ==== Out-of-kernel modules ===== > > This SIG also aims to provide out-of-kernel modules for CentOS that > might be accepted into the upstream kernel if submitted. This category > excludes: > > * modules whose primary functionality is already provided by an > actively maintained in-kernel module. This restriction might be problematic in some cases. E.g. if an existing in-kernel module is to be replaced by a (hopefully) better module. We probably want to provide this kernel module even though the existing in-kernel module has not yet been replaced in upstream (and especially not been backported). A somewhat recent example: exFAT. > > * modules whose licenses are not included in include/linux/license.h > (see license_is_gpl_compatible()). > [END] I'd probably change this section only a litte bit to avoid confusion and add an explanation for the restriction to GPL v2 copatible: [BEGIN] === Out-of-tree kernel modules === This SIG also aims to provide out-of-tree kernel modules for CentOS Stream. This is restricted to GPL v2 compatible kernel modules due to legal reasons. [END] The "GPL v2" restriction is mentioned twice in the description then. However I think this might not be bad at all. > > I hope this is helpful. > > Jeffrey Altman > > > > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > https://lists.centos.org/mailman/listinfo/centos-devel >