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@xxxxxxxxxx>
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@xxxxxxxxxx - info@xxxxxxxxxx
GPG public key ID: FF5F32A8
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
https://lists.centos.org/mailman/listinfo/centos
