[rhelv6-beta-list] kernel-release now appends the arch

Ned Slider ned at unixmail.co.uk
Fri Apr 30 21:31:19 UTC 2010


Stephan Wiesand wrote:
> On Apr 30, 2010, at 21:45 , Ned Slider wrote:
> 
>> Stephan Wiesand wrote:
>>> On Apr 29, 2010, at 21:10 , inode0 wrote:
>> <snip>
>>
>>>> I'm sympathetic to not liking changes that affect scripts and have
>>>> been bitten by changes in RHEL in the past but I don't really see a
>>>> use case where `uname -r` isn't still going to return the right
>>>> thing?! Maybe I'm not being imaginative enough.
>>> well, imagine an environment where external kernel modules are a necessity. Ok, they almost never really are, because almost always we could tell our users to get lost and use an OS that works for them. But, even setting aside the very few real cases where this actually isn't an option, I don't like the idea.
>>> So, please try to imagine you'd been maintaining a script that cares for updates of kernels *and* additional modules, making sure that each and every system that boots either comes up with the current kernel and all required modules available (Fedora/RHEL has *no* tool helping here - please prove me wrong) 
>> kmodtool for building kABI-tracking kernel independent kmod (kernel module) packages? But that uses 'uname -r' too ;)
>>
>> Anyway, you don't need to be rebuilding modules against every kernel - build them once with kmodtool and be done with it. Or better still, put in an RFE request to a 3rd party repo like elrepo.org for the modules you require and let someone else maintain them for you.
> 
> Right track, for sure. Alas, none of the modules I'm dealing with is using whitelisted ABIs only.  And btw, some of them are even closed source, I can't help it.
> 
> - Stephan
> 

Right. Not much you can do about closed source, but wrt building modules 
that require symbols that aren't defined in the ABI whitelist, please 
see here:

http://lists.elrepo.org/pipermail/elrepo-devel/2009-September/000056.html

Further, I've not had a chance to thoroughly test it yet, but I think 
the issue might now be fixed in RHEL6beta1.

Hope that helps.


PS - I forgot to link to the excellent documentation available for the 
RHEL Driver Update Program here:

http://dup.et.redhat.com/
http://dup.et.redhat.com/presentations/DriverUpdateProgramTechnical.pdf




More information about the rhelv6-beta-list mailing list