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