On 18/08/15 01:09, Jason Edgecombe wrote: > On 08/15/2015 07:52 PM, Ned Slider wrote: >> On 15/08/15 22:41, Jason Edgecombe wrote: >>> On 08/15/2015 10:56 AM, Ned Slider wrote: >>>> On 15/08/15 14:27, Jonathan Billings wrote: >>>>> On Aug 15, 2015, at 9:10 AM, Jason Edgecombe >>>>> <jason at rampaginggeek.com> wrote: >>>>>> What's the plan for fixing CBS to accommodate this? If I had a spare >>>>>> afternoon, what could I do to move this forward? >>>>> Really, the end goal is to have the kmod-openafs packages built for >>>>> every kernel release as it comes out, without removing the existing >>>>> kmod-openafs from the repo. This is why I separated it out from the >>>>> openafs spec/srpm, because it will need to be rebuilt every time >>>>> there is a new kernel. However, OpenAFS users want to have >>>>> historical kmods available. >>>>> >>>> Given that you really don't seemed to have moved forward in the last >>>> year, I would reiterate what I said a year ago: >>>> >>>> http://lists.centos.org/pipermail/centos-devel/2014-September/012047.html >>>> >>>> >>>> I really don't understand why you would not want to use the framework >>>> Red Hat provides to solve exactly this problem. You are trying to solve >>>> a problem that is largely already solved. >>>> >>>> Worst case scenario is you'd need to rebuild kmod-openafs for major >>>> point releases every 9-12 months (e.g, 6.5, 6.6, 6.7; and/or 7.0, 7.1, >>>> ...) where the kABI is broken for non-whitelisted symbols used by >>>> OpenAFS. That has to be a preferable solution for OpenAFS users than >>>> rebuilding against each and every kernel release. >>>> >>> Does yum check and prevent or warn you when installing a kABI module for >>> a non-matching kernel? How do I know which kmods match my kernel? >>> >> No, yum will only warn on symbols that may be missing, for example on >> older kernels. >> >> Look to see if the module weak links against the kernel in the >> corresponding weak-updates directory. >> >> Sometime a module can weak link but still not be compatible but it's >> uncommon and only likely to happen when going from one point release to >> another (e.g, 6.6 to 6.7) when Red Hat have changed the kABI of a >> non-whitelisted symbol used by your module. Pre-release testing will >> pick this up. Red Hat generally do not change the kABI within a point >> release. > > A few folks in the OpenAFS community have been burned by the kABI and > don't trust it, even for point RH releases. One gentleman was even > burned by elrepo. > People tend to not trust what they don't understand. kABI does exactly what it says on the tin - nothing more, nothing less. IMHO "burned" seems a bit strong but lets look at that. People tend to get "burned" when their expectations do not aline with reality. In reality kABI tracking kmods work seamlessly when the driver uses only symbols on the whitelist (and in my experience that is actually very few to none). As I understand, OpenAFS uses some non-whitelisted symbols so the reality is that openafs may break at point releases. It should work seamlessly for kernel updates between point releases. In other (your) words, you *may* get burned at a point release. Compare that to compiling against every single kernel release. That guarantees the existing module(s) will break for every new kernel release, so now instead of getting "burned" every 9 months at a point release, users now get "burned" at every kernel update. Lets look at an example. Every couple weeks RH release a kernel update but I can't update because my matching kmod-openafs isn't available yet. First I have to wait for CentOS to rebuild it and release the kernel update (lag). Then I have to wait for the SIG to rebuild their kmod-openafs against the newly built CentOS kernel (more lag). If I accidentally update my kernel and reboot - poof, I'm burned. Every time, guaranteed. If I don't update my kernel then compliance are on my case because I'm vulnerable to the latest CVE. Personally, if I'm gonna get burned I'd rather be burned every 9 months that every single time upstream releases a new kernel update. Of course in the real world, where people are using filesystem drivers in production, I'm sure they test any new releases before they put them into production so they never actually get burned. What they do get is a heads up when there is an issue, they file a bug, the driver gets rebuilt, the issue is solved and the bug is closed. It's that simple. I don't use OpenAFS so I really don't care if you build against every kernel or use kABI tracking kmods. As I've said before, there is no precedent in RHEL to build kmods against each kernel - kABI tracking kmods is the RHEL way. Given that you don't seem to have progressed from a year ago and kABI tracking kmods do not suffer from the problem you have made for yourselves, it just seemed like the obvious solution. A few folks in the OpenAFS community having a bad experience doesn't seem like a valid reason for throwing out the established way of doing things and adopting something that has the potential to cause far more issues and has no precedence in the RHEL ecosystem. If you want to deviate from the established method then I really think you need to (1) present a stronger case why you believe it doesn't work, and (2) present a viable alternative that significantly improves on the currently established methods. TBH it all seems fairly irrelevant now as I would imagine any users waiting for a solution are long gone by now.