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@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.