[CentOS] https://blog.centos.org/2020/12/future-is-centos-stream/

Thu Dec 10 18:09:48 UTC 2020
Gionatan Danti <g.danti at assyoma.it>

Il 2020-12-10 18:40 Brendan Conoboy ha scritto:
> Hey, you dropped Centos-devel from your reply.  I'll assume that was
> intentional, but if it wasn't feel free to quote any of this back
> there.

Hi Brendan, no, it was not intentional - I replied from the smartphone 
and I accidentally dropped the centos-devel list. I'll reply quoting the 
entire conversation to let others read your useful information.

> On Thu, Dec 10, 2020 at 9:26 AM Gionatan Danti <g.danti at assyoma.it>
> wrote:
> 
>> Il 2020-12-10 14:35 Brendan Conoboy ha scritto:
>>>> - are you going to keep stable ABI between Stream kernel
>> releases,
>>>> or
>>>> should we expect each kernel to break 3rd party drivers/modules?
>>> 
>>> All our kernel changes are implemented against the kernel ABI-
>> there
>>> is no point in time during release development when we have
>> interim
>>> changes in the kernel that ignore the symbols in the whitelist.
>> So
>>> basically if your experience of going from one minor release to
>>> another has been smooth, the incremental kernels between those two
>>> releases would also tend to run smooth, assuming whatever motions
>>> happen with the 3rd party drivers/modules behind the scenes
>> continue
>>> to happen (for example, rebuilding from source).
>> 
>> Let's forget about minor release upgrades and focus on the
>> incremental
>> kernel updates between point releases for a moment. Can we expect a
>> stable kernel ABI for these releases, or should we expect breaking
>> changes? In other words, should 3rd party kmod be constantly updated
>> for
>> *any* kernel released on the Stream channel, or can we expect them
>> to
>> keep working until a "next-release" kernel appears?
>> 
>> Regarding symbol whitelist, I understand it as related to a single
>> minor
>> releases - ie: all kernels of 8.3 branch will obey it, but this can
>> be
>> false for kernel on, say, 8.4
>> 
>> Am I missing something?
> 
> I think it's a question of nuance.  In broad strokes we don't break
> the kernel ABI as outlined by the whitelist starting with the first
> major release.  In fact, taht whitelist grows throughout the life of
> the release, making the ABI more predictable.  The problem you've
> likely experienced is that loadable kernel modules have access to
> symbols not included in the whitelist.  Whether we're pushing new code
> upstream or backporting new code from upstream, we endeavor to keep
> symbols the same, even if they aren't on the whitelist.  But if for
> strong technical reasons it's better to change a symbol, that will
> happen upstream, and if it wasn't part of our whitelist, it can happen
> in RHEL as well.  Usually these changes only require minor updates in
> the loadable kernel modules, but for an end user this is the
> difference between a module loading or not loading, so the impact is
> glaring.
> 
> I'm not sure how things will take shape with CentOS Stream and
> external drivers, whether some gating activity wil elrepo will hold
> back kernel updates until elrepo is updated, or if a SIG will form, or
> some other thing.  All I can say for sure is that when you have a
> group of people with common problems, they will create solutions, and
> we want those solutions for CentOS Stream.  So we'll work it out, I'm
> just not sure how yet (kABI isn't my focus, I'm simply familiar with
> the dynamics because I was the overall RHEL 8 development lead).
> 
>>>> - what/how many synchronization points are going to be with RHEL
>>>> releases?
>>> 
>>> I'm not sure I'm interpreting your question correctly, could you
>>> restate?  I don't want to hit you with detailed process
>> information
>>> only to find out I'm answering the wrong question!
>> 
>> With Stream, all is going to change constantly. We will have any
>> "sync
>> point" where Stream is 100% identical to a specific RHEL point
>> release?
> 
> OK, I understand now, thanks!  I don't think there will be a point
> where a RHEL minor release compose will be NVR identical to a CentOS
> Stream compose, though they will be pretty close.  The reason for this
> is that there is a period of time where we're working on 2 RHEL
> releases at once: The one that is about to release, and the one that
> will follow.  CentOS Stream, I believe, will follow the source tree of
> "the one that will follow."  All the same fixes will be there, but
> CentOS Stream will also get additional fixes and features not included
> in the near term RHEL release.
> 
>> Thank you for taking the time to reply.
>> Regards.
> 
> I appreciate the questions!  Regards,

Thank you for the clear replies.
Regards.

-- 
Danti Gionatan
Supporto Tecnico
Assyoma S.r.l. - www.assyoma.it
email: g.danti at assyoma.it - info at assyoma.it
GPG public key ID: FF5F32A8