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:
Akemi Yagi <[log in to unmask]>
Reply To:
Akemi Yagi <[log in to unmask]>
Date:
Mon, 7 Jun 2010 12:29:36 -0700
Content-Type:
text/plain
Parts/Attachments:
text/plain (16 lines)
On Mon, Jun 7, 2010 at 11:53 AM, Stephan Wiesand
<[log in to unmask]> 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.

I have no problem using the kABI-tracking kmod-nvidia package from
ELRepo on my SL-5 systems. We (ELRepo) are closely working with Red
Hat devs to make implementation of kmods in RHEL6 as smooth as we can.
 So, perhaps, we can work with SL devs to accommodate the needs that
are unique to SL (if necessary).

Akemi

ATOM RSS1 RSS2