SCIENTIFIC-LINUX-DEVEL Archives

June 2010

SCIENTIFIC-LINUX-DEVEL@LISTSERV.FNAL.GOV

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Phil Perry <[log in to unmask]>
Reply To:
Phil Perry <[log in to unmask]>
Date:
Mon, 7 Jun 2010 20:37:22 +0100
Content-Type:
text/plain
Parts/Attachments:
text/plain (43 lines)
On 06/07/2010 07:53 PM, Stephan Wiesand wrote:
> Hi Troy,
>
> On Jun 7, 2010, at 20:15 , Troy Dawson wrote:
>
>> *Kernel-modules
>> They are a necessary evil.  How should we handle them on SL6
>
> Very good question. Unfortunately, it's hard to answer right now. The 'kernel-module-' way has worked well for us - some overhead, but no ugly surprises. KABI-dependent modules are certainly an attractive alternative. Alas, the whitelisted ABI was much too restricted in the past to be useful for our purposes (not usable for the nvidia driver nor the AFS client, to give just two examples). It seems that's being worked on, and circumstances are likely to change before RHEL6 GA. My current proposal would be to stay with kernel-module- except where KABI-aware kmods work cleanly.
>

We (at elrepo.org) have started to look at building kABI modules under 
RHEL6beta1 and the differences from RHEL5. As Stephan said, there were 
initially some issues (on RHEL5) building modules that required symbols 
not whitelisted within a particular kABI, but we were able to work 
around those. Within el6, things are somewhat different - the kernel now 
provides *every* symbol as a dependency so you can build against them 
even if the symbol isn't on the whitelist, which should make packaging 
somewhat easier.

I'm not overly familiar with the 'kernel-module' method used in SL5. 
What I anticipate from RHEL6, much as with RHEL5, is that kABI-tracking 
kmods should work seamlessly within any update release (eg, 6.0, 6.1, 
6.2 etc), and ideally should also work across update releases too. So, 
at worst, you might need to rebuild the occasional kmod package against 
a new update release kernel when it comes out (for example, against 6.1 
or 6.2 release kernel). But largely, it should just be a case of build 
once and forget it which is great for both package maintainers and 
package users.

The kmodtool script in RHEL6 isn't hugely different from that in RHEL5, 
and we have an example kmod package in our el6/testing repository 
containing SPEC file and scripts that can be used as examples for 
building kABI-tracking kmod packages for RHEL6.

If you decide to go the kABI-tracking kmod route then we'd be happy to 
help, but it's really not that difficult once you get the process laid down.

Regards,

Phil
http://elrepo.org

ATOM RSS1 RSS2