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 __________________________________________________