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:
Phil Perry <[log in to unmask]>
Reply To:
Phil Perry <[log in to unmask]>
Date:
Wed, 13 Jan 2010 17:19:48 +0000
Content-Type:
text/plain
Parts/Attachments:
text/plain (152 lines)
On 01/13/2010 04:49 PM, Troy Dawson wrote:
> 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

You're welcome.

I didn't mean to imply to take discussions away from this list. I think 
all the elrepo team are also subscribed to this list so no reason not to 
have discussions here when they relate to SL :)

As you're probably aware, the kABI-tracking kmod system we use is 
essentially as provided by Red Hat as part of their Driver Update 
Programme [1]. Red Hat has provided us with the framework and we merely 
use that to provide backported kernel drivers. How we do things in RHEL6 
(and compatibles) will depend largely on the framework provided with and 
for that release.

We've had a few conversations with Jon Masters (Red Hat) about 
limitations of the current system, what we'd like to see in RHEL6 and 
how they plan to handle kernel modules within that release. At present I 
don't have a clear picture what the policy will be, and looking at the 
latest Fedora release doesn't clarify the picture in my mind much 
either, but I know Jon is working hard on it and is keen to talk to and 
obtain feedback from users of the current framework.

[1] http://dup.et.redhat.com/

ATOM RSS1 RSS2