[CentOS-devel] RFC: kmods SIG Proposal

Wed May 26 19:19:52 UTC 2021
Jeffrey E Altman <jaltman at auristor.com>

On 5/24/2021 4:10 PM, Peter Georg (peter.georg at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: jaltman.vcf
Type: text/x-vcard
Size: 271 bytes
Desc: not available
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20210526/edac48b3/attachment-0005.vcf>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20210526/edac48b3/attachment-0005.sig>