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