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-0003.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-0003.sig>