On 5/24/2021 4:10 PM, Peter Georg (peter.georg@physik.uni-regensburg.de) wrote:
On 23/05/2021 21.00, Jeffrey E Altman wrote:
On 5/23/2021 10:32 AM, Peter Georg
=== 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?
I'm in favor of s/third-party external/out-of-tree/g and s/in-kernel/in-tree kernel/g.
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?
I do not think so.
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.
I might argue that the "exFAT" example is covered since the in-tree kernel module was not actively maintained.
* 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 compatible:
ok