On 20/01/2021 09.08, redbaronbrowser via CentOS-devel wrote:
There are four main goals of this SIG:
First, break down changes in the Stream version 4.18.0 kernel into individual patches. When possible, document the source the patch is from and the purpose of the patch. Moving forward also document which Stream kernel package revision introduced the patch.
Second, build CentOS Plus kernel for Stream.
Third, package newer LTS kernels during the LTS lifespan. These would be available as alternative kernels for Stream similar to the CentOS Plus kernel.
Fourth, work on tools for better delivery of live security patches to be applied via kpatch.
The reasoning for this SIG is to improve the openness of kernels available through Stream.
Normally a distribution upstream would have access to which patch or commit each addition to the kernel belongs to. The patch name or commit comment would also give information as to the purpose of the patch. Stream's kernel reports to be 4.18.0 but uses a tar that is 110% the size of a true 4.18.0 tar. A breakdown of the additional 10% is not provided. Hence Stream's kernel still functions similar to a downstream rather than providing what is expected for a successful upstream project.
This SIG would help close the kernel openness gap by documenting the changes. Stream users would then be in a better position to track down individual patches that cause regressions or bugs.
This SIG would also help smooth the adoption of Stream for users that depend on CentOS Plus kernel features.
Next, this SIG should help improve feedback to the LTS kernel developers. Tracking LTS kernel changes may also help with documenting some changes in the primary Stream kernel.
Lastly, this SIG should help improve kernel security by promoting methods to enable kernel security updates even when a reboot of the system is not possible.
Replying directly to the head of this topic now as I'm not sure which branch it fits best.
As announced by Brian Stinson, he was available on IRC yesterday (twice) to discuss anything related to kernels and this proposal in particular. Sadly there have only been a few people to discuss this matter.
Most of the discussion was indeed about the fifth main goal that I proposed in a follow up mail to the original proposal: Package external kernel modules
This does not mean that the other proposed goals are not worth investigating, but simply not enough people have shown up on IRC yesterday to discuss these.
Brian also mentioned that there might actually be fewer challenges blocking a SIG to build kernel modules in CBS than he initially thought (especially if secureboot is not a hard requirement, i.e. can be tackled at a later stage). So we might be able to start earlier than expected.
It seems like starting with packaging external kernel modules is a good starting point for the proposed SIG. Hence we concluded to start gathering a list of kernel modules people are interested in building for CentOS Stream here on the mailing list. Of course this is not a pure wish list, but people should also commit to be part of the process / SIG. On IRC the following kernel modules have been mentioned / discussed as potential candidates to be built by a kernel SIG. I added information where these modules can currently be retrieved for RHEL and CentOS Linux (only one source for each module). However these are probably not compatible with CentOS Stream.
- isci (ELRepo, kmod) - mlx4 (ELRepo, kmod) - lustre-client (Lustre upstream, kmod and dkms) - nvidia (nVidia, kmod and dkms) - rocm (AMD, dkms) - wireguard (ELRepo, kmod)
Please feel free to extend this list with modules you are interested in. I suggest you also add the source you currently get these modules (for RHEL/CentOS Linux) from if any is available.
Best
Peter