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

Josh Boyer

jwboyer at redhat.com
Thu Dec 10 12:10:36 UTC 2020


On Wed, Dec 9, 2020 at 3:49 PM Phil Perry <pperry at elrepo.org> wrote:
>
> On 09/12/2020 19:01, Brendan Conoboy wrote:
> > On Wed, Dec 9, 2020 at 10:04 AM Phil Perry <pperry at elrepo.org
> > <mailto:pperry at elrepo.org>> wrote:
> >
> >     On 09/12/2020 17:40, Stef Walter wrote:
> >      > On Wed, Dec 9, 2020 at 6:33 PM David Hrbáč <david-lists at hrbac.cz
> >     <mailto:david-lists at hrbac.cz>
> >      > <mailto:david-lists at hrbac.cz <mailto:david-lists at hrbac.cz>>> wrote:
> >      >
> >      >         I don't use CentOS Stream, I use RHEL. I use RHEL to develop
> >      >         software
> >      >         for RHEL and compatible OS clones, including CentOS. If
> >     Stream
> >      >         retains
> >      >         binary compatibility, and specifically kernel ABI
> >     compatibility,
> >      >         then
> >      >         the users of the software packages we develop can continue to
> >      >         use them.
> >      >         If not, they can't. Simple as that. So please don't push
> >     rolling
> >      >         kernel
> >      >         updates to Stream that break the kernel ABI.
> >      >
> >      >
> >      > Indeed. If any such broken change (eg: that breaks kernel ABI) is
> >     pushed
> >      > to Stream, that is treated as a serious problem by the RHEL
> >     engineering
> >      > teams. We have the necessary process in place to QE test changes
> >     before
> >      > they arrive in CentOS Stream.
> >      >
> >      > I understand this fact alone is not a panacea for all the problems
> >      > people are highlighting. But it does seem to cover your use case.
> >     From a
> >      > regression, stability, ABI, and kernel ABI perspective, it is the
> >     goal
> >      > and focus of many of us in RHEL Engineering for CentOS Stream to
> >     be stable.
> >
> >     Hi Stef,
> >
> >     Thank you for your response. You do realise I'm not just talking about
> >     whitelisted kernel symbols, but the whole kernel ABI?
> >
> >     Whilst the RHEL kernel ABI whitelist is great in principle, in practice
> >     I am yet to find a kernel driver that uses only symbols on the
> >     whitelist. As I said previously, every single driver I maintain broke
> >     between RHEL8.2 and RHEL8.3 due to changes in the kernel ABI.

Just to touch on this a bit, the reason the RHEL kABI whitelist exists
is because the upstream Linux kernel explicitly does NOT have a kernel
ABI.  Given that you maintain out of tree drivers, I'm sure you know
this but it might not be evident to anyone that doesn't.  So the RHEL
kABI whitelist is there to express what RHEL is committing to keep
stable for a kernel ABI for 10 years while dealing with an upstream
that doesn't care at all.

> > Yes, the symbol list is helpful, but it's rarely 100%, so we're going to
> > have to iteratively do better.
> >
> > Just to be clear, I don't think this is your job or David's job to
> > solve, just knowing that if we collectively solve it, it makes CentOS
> > Stream a more viable option for you and others was the insight I was
> > hoping for.  There are probably many of these, but this is the one I'm
> > hearing repeatedly in this thread.  In the months ahead there are going
> > to be numerous, uh, "opportunities", to solve these sorts of things
> > together :-) If the kind of thing you can bring is what does and doesn't
> > work for you and why, I'll take it.
> >
>
> Great. Once kernel-4.18.0-257.el8.x86_64 makes it into Stream, I'll be
> happy to test and feed back. Any ETA on that? I see it was built a week
> ago on koji

I'm sure the CentOS rebuild of 8.3 that just came out took some time.
And many of the people that do the work are now discussing the
announcement this week.  Let's see what they can do in the next few
days :)

josh


More information about the CentOS-devel mailing list