SCIENTIFIC-LINUX-USERS Archives

January 2010

SCIENTIFIC-LINUX-USERS@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:
Troy Dawson <[log in to unmask]>
Reply To:
Troy Dawson <[log in to unmask]>
Date:
Wed, 13 Jan 2010 10:49:50 -0600
Content-Type:
text/plain
Parts/Attachments:
text/plain (129 lines)
Phil Perry wrote:
> On 01/13/2010 03:14 PM, Troy Dawson wrote:
>> Alan Bartlett wrote:
>>> 2010/1/12 Akemi Yagi <[log in to unmask]>:
>>>> On Tue, Jan 12, 2010 at 2:08 PM, g <[log in to unmask]> wrote:
>>>>> Akemi Yagi wrote:
>>>>>> Just a note about the ndiswrapper package from the ELRepo repository.
>>>>>> It comes with a kernel-version independent, kABI-tracking kernel
>>>>>> module.
>>>>> i believe all packages from 'elrepo' are kernel independent.
>>>>>
>>>>> i have 2 packages from them that have gone thru 3 kernel updates
>>>>> and are working just fine like day they were first installed.
>>>> Yes, all kmod packages from ELRepo are kernel independent and should
>>>> survive kernel updates quietly. :)
>>> To expand upon Akemi's comment regarding kmod packages from ELRepo --
>>>
>>> All kmod packages are built to be kernel independent, kABI tracking
>>> for all the released RHEL 5 kernels (unless otherwise stated). Hence
>>> ELRepo kmod packages are appropriate for all RHEL 5 based derivatives,
>>> i.e. Scientific Linux 5 and CentOS 5, as long as their kernels do not
>>> deviate from the ABI published by TUV.
>>>
>>> A brief note about ELRepo, for users of Scientific Linux. ELRepo is
>>> entirely independent of (and is not endorsed by) Red Hat and the
>>> CentOS project. It is, however, acknowledged by both and there is a
>>> communication / co-operation channel to the relevant kernel
>>> engineering team at Red Hat. The ELRepo admin team have significant
>>> experience with RHEL, Scientific Linux and CentOS.
>>>
>>> Alan.
>> Hi Alan,
>> Thank you for explanation. I have to admit that I hadn't looked at
>> ELRepo before today, although I've heard of it. It looks very useful for
>> people who need drivers.
>> A couple of questions
>> I see you have both nvidia-x11-drv as well as kmod-nvidia. Are these
>> independant, or do you have to have both installed?
>>
>> I am somewhat new to kABI kernel modules. I know the theory, but not
>> much else.
>> In your experience with RHEL5, how often has RedHat broken or modified
>> the ABI's, requiring you to update your kmod package?
>>
>> Troy
> 
> Hi Troy,
> 
> If I may be permitted to answer as maintainer of the ELRepo nvidia packages.
> 
> Generally, our (elrepo's) kmod packages only provide the kernel 
> module(s) (driver.ko), and associated depmod.d .conf entry. The nvidia 
> package is a little different as there are also the accompanying 
> proprietary X11 libs, in this case provided by the conventional 
> nvidia-x11-drv RPM package. So to answer your question, kmod-nvidia 
> requires nvidia-x11-drv, and vice versa, so they must both be installed.
> 
> Your second question is an interesting one, and Alan may be better 
> qualified to give a more technically correct explanation, but I'll do my 
> best knowing he'll correct me where I slip up :)
> 
> Generally, kABI should be consistent across all kernel releases within a 
> Red Hat release. So, for example, the kABI of RHEL5 should not change 
> throughout the life of the product. But as you may suspect, that is not 
> always the case.
> 
> We have built around 60 kmod packages, and from that experience we have 
> found that the kABI is always consistent within an update release (e.g, 
> 5.0, 5.1, 5.2 etc). For example, we have not, and would not expect to 
> observe any kABI breakage for kernels released under the update release 
> 5.4 (2.6.18-164.x). What we have observed is some breaking of the kABI 
> *between* update releases.
> 
> Generally, the vast majority of our packages work fine across all kernel 
> update releases (5.0 through to 5.4, at present). However, there are 
> some exceptions. Nvidia, for example, is one. The current kmod-nvidia 
> release was built against kernel-2.6.18-128.el5 (5.3), and is not 
> compatible with earlier kernel releases, suggesting that some kABI 
> breakage occurred for the 5.3 release that affects kmod-nvidia. 
> Interesting, kmod-nvidia works seamlessly going forward to 5.4 so in 
> this instance there was no change in the kABI (affecting kmod-nvidia) 
> between 5.3 and 5.4. In this instance we simply have a Requires: on the 
> kmod-nvidia package for kernel >= 2.6.18-128. If users are stuck on 
> older kernels for any reason and need kmod-nvidia, then we could in 
> theory build a version-release for them compiled against the kernel 
> release required although such a situation hasn't arisen yet.
> 
> Some other larger packages such as kmod-alsa and kmod-video4linux that 
> provide hundreds of modules exhibit minor kABI breakage where, when 
> built against the latest kernel, a few modules then don't weak-link 
> against earlier kernels due to kABI breakage affecting only those modules.
> 
> But for the vast majority of modules, the kABI is consistent as you 
> would hope (expect), and a kmod package will work seamlessly across all 
> kernel releases. In fact, I can't recall any other package affected by a 
> change in the kABI.
> 
> Finally, we would welcome you to join the elrepo mailing lists (and any 
> other SL users). I don't know how many (non kABI-tracking) kmod type 
> packages you currently have within SL (if any), but I would imagine the 
> main benefit of kABI-tracking kmods for someone like yourself would be 
> that you would only need to build them once rather than having to 
> rebuild against every kernel release, thus making it a great time saver!
> 
> Regards,
> 
> Phil
> 

Hi Phil,
Thanks for your explanation.  I appreciate it.  I'll go over and join 
your mailling list for further discussion.

Just so you know, we use the kernel-module rpm system, very similar and 
compatible with atrpms kdml.  Everything is already setup so that when 
we have a new kernel, I only have to run one script and all the kernel 
modules are built, so it's not too big of a hassel.

We also have nvidia dkms packages in our contrib area.

But we are looking at various ways of doing kernel modules for SL6.

Troy
-- 
__________________________________________________
Troy Dawson  [log in to unmask]  (630)840-6468
Fermilab  ComputingDivision/LSCS/CSI/USS Group
__________________________________________________

ATOM RSS1 RSS2