[CentOS-devel] [EXT] Balancing the needs around the CentOS platform

On 19/12/2020 21.09, Gordon Messmer wrote:
> On 12/19/20 1:13 AM, Peter Georg wrote:
>> However I disagree on one point: You mention CentOS Stream can cover 
>> "95% (or so)" of the current users. As long as 3rd party drivers are 
>> not working with CentOS Stream the number will be lower. 
> 
> 
> Do you have a reason to think that > 5% of users need 3rd party drivers?

I never said that. I just assume that the amount x of use cases CentOS 
can not cover plus the amount y of users that need 3rd party drivers is 
greater than 5%.
So yes, you are right, it is an assumption by myself, but so has been 
the assumption of 95% by Karsten.
There are many 3rd party driver / kernel modules you probably do not 
need. That is good for you, but other people depend on these. I wish all 
software/hardware I use would be supported 100% by upstream kernel, 
sadly this is not the reality. Even if they are supported upstream, 
hardware vendors often supply backports for EL (e.g. AMD ROCm).


> 
> 
>> In my opinion, the only way to guarantee compatibility is by 100% 
>> kernel ABI compatibility.
> 
> Stream is going to continue to get the same kernel that RHEL gets, it's 
> just going to get updates earlier.
> 
> In the past, users with binary 3rd party drivers would need to wait a 
> while after a point release before they could update their kernel.  In 
> CentOS Stream, they'll have to wait a while after a kernel package 
> update before they can update their kernel.
> 
> There's really very little changing, here.  The point releases are going 
> away, so the date of kernel updates is less predictable, but the 
> solution hasn't changed at all:  If you use a binary 3rd party kernel 
> module, you need a process in place to block kernel updates until your 
> 3rd party kernel modules are available

It's not that simple. Currently we have a kernel build 4.18.0-x.y in 
CentOS 8. As Trevor already told you, kABI changes only (there might be 
exceptions) happen when x is changed. x is fixed for a particular minor 
release.

In practice this currently (i.e. with CentOS Linux) means that at some 
point all 3rd party drivers will support a particular kernel version x 
and all its updated versions x.y. I.e. we are good to upgrade to this 
particular minor release. We can even update the kernel within this 
minor release to get security fixes.

With CentOS Stream x is changing frequently, y does not exist at all. In 
the best case, the same build x used in a minor release is also 
available in CentOS Stream (actually it should be available in any 
case). Up to this point everything seems fine as you said, I "just" lose 
the opportunity to update the kernel as long as any 3rd party driver I 
have installed is not yet available for version x+? [1]. Nothing new, 
just like it has always been? Here's the tricky part: In CentOS Linux I 
can update the kernel only changing "y" and retaining kABI compatibility 
to fix security issues. In CentOS Stream these security fixes will be 
part of a new kernel version x+? not having any guarantee about kABI. 
Any kernel version x.y released in RHEL will NOT be available in CentOS 
Stream.

Maybe this somewhat longer explanation helps you to understand this issue.


[1] One should also note here that I need to have installed this 
particular kernel version x as it will not be available from official 
repositories once x+1 is released. Which in turn means that I somewhere 
have to store ALL ever release kernel (and directly dependent) rpms as I 
never know which version "x" will be used for the next minor release and 
hence be the "chosen" version all 3rd party drivers/kernel modules will 
be built against.


Peter




> 
> 
> _______________________________________________
> CentOS-devel mailing list
> CentOS-devel at centos.org
> https://lists.centos.org/mailman/listinfo/centos-devel
s