On 23/05/2021 21.00, Jeffrey E Altman wrote:
On 5/23/2021 10:32 AM, Peter Georg (peter.georg@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@centos.org https://lists.centos.org/mailman/listinfo/centos-devel