Thank you Axel,
Since they were similarly named, and I knew that you were in the
discussion at the beginning (I was too, before I realized I was in over
my head) I had thought they had taken your working model.
I need to read alot more before answering again.
Troy
Axel Thimm wrote:
> 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...
>>
>
--
__________________________________________________
Troy Dawson [log in to unmask] (630)840-6468
Fermilab ComputingDivision/CSS CSI Group
__________________________________________________
|
