Re: Re: Too many kernels?

On Thursday 03 July 2008 01:17:10 pm Axel Thimm wrote:
> On Thu, Jul 03, 2008 at 10:50:35AM -0400, Jarod Wilson wrote:
> > Red Hat suggests building once for each flavor/arch combo and being done
> > with it. As long as the required kernel symbols are present, they'll
> > keep working. You make the kernel module deps on the necessary kernel
> > symbols, which are provided by the kernel package. For example, the
> > packages provided here...
> >
> > http://rhn.redhat.com/errata/RHBA-2007-0654.html
> >
> > ...are designed to work with any version-release of a given arch/flavor
> > RHEL5 kernel.
> >
> > But then maybe you already knew that, and don't like that scheme much...
> >
> > :)
>
> I'd love it if it would work :)

Well, it does (should), for modules that only use whilelisted interfaces...

> > But that's what's recommended to all ISV's who build kernel modules
> > for RHEL5, and so far, its worked out great. Of course, if some out
> > of tree driver requires a symbol not on the whitelist (i.e., not in
> > the kernel's Provides:), you lose, but...
>
> My experience is that there is no guaranteed kernel ABI nor API by
> RHEL. Otherwise the kmdl builds would not start to fail between say
> the 53 series and the 92 ones. On every quarterly update I have to fix
> several kmdl packages for RHEL due to backports. Usually with RHEL4/5
> these are wireless updates.

There *is* a guaranteed kernel ABI, as defined by the kABI whitelist. I 
suspect a large portion of the things you're building use non-whitelisted 
symbols, and thus the breakage, as I mentioned before. :)

> Also at the very least I know of a glibc ABI discrepancy that was
> fixed in 62, so I'm quite sure that there is no such stable ABI yet,
> and since upstream will never provide one, it is very difficult for a
> vendor to provide one (unless in deep maintenance mode where only
> severe bugfixes/security issues, but no enhancements are addressed).

Yep, its a tough line to walk, providing both enhancements and a stable ABI... 
Which is partially why only certain symbols end up on the whitelist, and only 
after technical review.

> But speaking of policies I meant more the "you are required to update
> withing XYZ days of an update to have Red Hat support etc.". If a
> kernel is not anymore supported by Red Hat or CentOS then no kmdl
> should be built for it.

If you're hitting a bug, you certainly might be asked to update your kernel to 
the latest errata kernel to see if said bug is already fixed. But generally, 
I don't think Red Hat mandates that anyone must update their kernel to 
continue to get support, all shipped kernels are supported and running, say, 
the original RHEL5.0 kernel doesn't negate your support contract...

-- 
Jarod Wilson
jwilson-H+wXaHxf7aLQT0dZR+AlfA@xxxxxxxxxxxxxxxx