On Fri, Nov 17, 2006 at 11:09:52AM -0600, Troy Dawson wrote:
> Hi Stephan,
> No flame war at all ... at least I hope not.
> 
> With S.L. 5 we will move to the new way of doing kernel modules, with is 
> the "kmod" scheme.
> This scheme is really the correct way of doing things, since it is 
> integrated all the way into rpm ... or at least it's macro's.

IMO it has some very serious design flaws.

> It is also the way that RedHat will be doing their kernel modules
> (thank goodness), so we won't have two ways of doing kernel modules
> in S.L. 5.
> 
> So if this is the correct way to do things, why isn't it in S.L. 4.x and 
>  3.0.x?
> Reason One: Stability.
> We don't want to do major changes to yum in the mature releases.  That's 
> why S.L. 3.0.x is still at yum 2.0.x, and why S.L. 4.x is still at yum 
> 2.4.x.
> Changing the way we do kernel modules would really be a drastic change 
> for our users.
> 
> Reason Two: rpm
> Axel might know the details about this better, so if I'm wrong, I apologize.
> Part of the magic of the "kmod" way is in rpm itself.  I don't know if 
> it's the macro's, or built into the code, but the newer rpm knows what 
> to do with objects marked as kernel modules.

In fact it is the other way around. kmods break rpm semantics
especially in the context of enterprise grade update methology,
e.g. keeping several kernels around. At their very best kmods can work
only if you require all users to always run just the latest
kernel. That's due to the lack of uname-r-in-name. See the links below
for full details.

> If you think we're stubborn about upgrading to the next release of yum, 
> just try to ask us to update to the next release of rpm.  The answer is 
> no, that's not happening, at least not in the main release.
> 
> I'm actually glad you brought this up, because switching over to the 
> "kmod" way will require re-doing the various kernel module rpm's that 
> have been written.
> As I look at the few that I have, this doesn't look like a major 
> re-write, just some different settings in the spec header section, 
> and/or the individual package header sections.
> 
> Does anyone have any reasons other than having to redo the kernel-header 
> rpm's, why we shouldn't move to the "kmod" way of doing things with S.L. 5?

http://fedoraproject.org/wiki/AxelThimm/kmdls/kmods_vs_kmdls_at_a_glance
http://fedoraproject.org/wiki/AxelThimm/kmdls

I tried to get this issue forward before FC6/EL5, but after a long
discussion the vote timed out (only 6 out of 10 people voted at all,
and 6 were required for any change of course):

http://fedoraproject.org/wiki/AxelThimm/kmdls/voting

FWIW there are openafs rpms for SL at ATrpms. And there is a
yum-plugin-kmdl for ensuring coinstallation of kmdls upon arrival of
new kernels (or even later since there is usually no warning in
advance that a new kernel package is to be released, so there is some
lead time between new kernel packages and new kmdls for that kernel).

> Troy
> 
> Stephan Wiesand wrote:
> >Hi Enrico, Troy, All,
> >
> ...snip...
> >
> >But regarding SL5, there's one design question to be answered:
> >
> >Should/will SL stay with the "kernel-module" scheme for kernel modules, or 
> >adopt the "kmod" scheme that's in use in FC6 and EL5beta, and will most 
> >likely be in EL5 GA? I don't have too strong an opinion on this issue
> >(both have their pros and cons), but it would be nice to have the giants'
> >ruling on it...
> >
> >Hope I haven't started a flame war now,
> >	Stephan
> >
> ...snip...
> 

-- 
Axel.Thimm at ATrpms.net