On Mon, May 14, 2007 at 09:34:40AM -0400, Brian Long wrote: > On Mon, 2007-05-14 at 12:19 +0200, Axel Thimm wrote: > <snip> > > But let me give a general rant regarding both kmdls, dkms and any > > other kernel module packgaing scheme: Of course when a new kernel > > update breaks its API both systems will miserably break down. And > > sadly RHEL4 had major wireless ext updates in the core with subminor > > kernel rpm releases always managing to break wireless kmdl builds. The > > fact that only half the wext 18 or similar were backported didn't help > > either, and several "rhel4 hacks" had to be introduced to fool the > > packages that they should assume the wext of version such and such. :/ > > > > As said this breaks all packaging schemes as it requires human > > intervention to adjust the code, and this is the main work in > > mainatining kernel modules packages. If such things don't happen (and > > the RHEL5 updates haven't yet done such backports) kmdls and dkms work > > fine. Let's hope RHEL5 keeps better ABI stability than RHEL4. > > > > (Sorry if RHEL4 kernel maintainers feel ranted upon, I understand that > > their backporting was for good reasons, e.g. to add better wireless > > support to RHEL4, still the ABI suffered too often) > > I'm sorry to hear the WEXT 18 backport caused you such a headache as I > was the Red Hat customer who pushed for it. :) My team at the time > also pushed for wpa_supplicant and I believe it was just included in > 4.5.
np, I understand the need for such changes. But this brings some light into a general issue - there are two ways to deal with it enterprisely: o realize that there is no kernel API/ABI stability support, e.g. no external kernel module build support yet in place. o move more of the kernel extra patching outside the main kernel package (whenever possible, some parts can't be built oot), e.g. modularize the kernel rpm into a core part and kmdl like subparts that are built separately. The latter scheme has the nice side-effect that the core package really need to be touched only very rarely and an update of the wifi components don't require a rebuild of the graphics drivers. Which also means better QA overall, since the lifetime of core & component is longer. But we're not there, yet. Currently the former method is the de-facto method even though RHEL is theoretically endorsing ISVs. The various kmdl/dkms schemes probably need to convince a bit more. And maybe customers need to cry out for kmdl support instead of patching in stuff ;) (I know the same discussion happens between RHEL and customers using openafs kmdls about openafs support BTW. If every customer that uses kmdl would endorse pushing kmdl methology into RHEL and Fedora, we'd have then in by now :) -- Axel.Thimm at ATrpms.net
pgpLWtBJ2zu5h.pgp
Description: PGP signature
_______________________________________________ rhelv5-list mailing list [email protected] https://www.redhat.com/mailman/listinfo/rhelv5-list
