I've added some bits of kabi discussion to the wiki: http://fedoraproject.org/wiki/AxelThimm/kmdls On Tue, Aug 15, 2006 at 02:53:03AM +0200, Axel Thimm wrote: > On Mon, Aug 14, 2006 at 05:33:14PM -0700, Toshio Kuratomi wrote: > > On Tue, 2006-08-15 at 01:57 +0200, Axel Thimm wrote: > > > On Mon, Aug 14, 2006 at 08:06:51PM +0200, Thorsten Leemhuis wrote: > > > > /lib/modules/kabi/MODULE/VERSION-RELEASE/{MODULES...}.ko > > > > > > We already discussed that last week. You are moving the versioning > > > problem of the modules away from rpm to module-init-tools. > > > > > Yes and no. He's moving it to /sbin/weak-modules which seems like a > > logical place. weak-modules has to understand how to place kernel > > modules (or links to them) into the tree for depmod and friends to find > > them. Right now it does this for kabi. It's not a big conceptual > > stretch to think that it could do this for kmod as well. > > > > > You need to encode evr into the path and then teach depmod or any > > > helper application to order according to rpm's evr scheme. > > > > > Not necessarily. The helper application has to support a versioning > > scheme. We can make the ondisk directory layout match the helper's > > versioning scheme independent of the rpm evr. Certain versioning > > schemes on the part of the helper would be easier for us to work with, > > of course :-) > > Then what use would the evr be at all? yum is taught to ignore it and > module-init-tools will ignore it, too. So if I issue a new release of > the module it get's either coinstalled, or if there really is no 1-1 > mapping it may even start overwrite the previous module. > > > > It's not an improvement, it's outsourcing a packaging/versioning > > > problem to the wrong domain. > > > > module-init-tools has to start supporting some sort of versioning scheme > > in order to support kabi. I'd argue that even without kabi, the tools > > should support a defined order in which they will choose what kernel > > modules to load. Leaving it undefined is a drawback for more than > > package managers. > > > > > > Axel, do you see any reason Thorsten's proposal wouldn't work? > > Inability to replace a broken module? Ignoring evrs on modules? > E.g. I can never go back to a previous version if 3w-9xxx turns out to > be broken? Solving a problem by moving it to another domain? > > kabi makes no sense for Fedora. It is soemthing for people wishing > there existed a kernel abi like ISV/IHVs with mostly closed source > content. Upstream kernel development has clearly stated that even due > to political reasons there will not be a kernel api, it's documented > in every kernel source and on every Fedora system in kernel-docs. > > Vendors that will keep their kernels stable, e.g. only apply security > bugfixes, can say that their have some kind of kernel abi and even > give it a vendor-specfic name/value. Like RHEL4 was exporting kabi = > 4.0 or similar. This makes only sense for RHEL and SLES, Fedora's kabi > changes with every kernel release. Even RHEL5 will change it's "kabi" > with every quaterly release, just like RHEL4U4 shows us. There is no > other way to support new drivers and introducing kernel abi *metrics* > is not introducing a kernel api/abi, which only the kernel developers > could introduce, which they deliberately won't. > > So kabi is of use only to ISV/IHVs with potentially closed source (or > at least not commited upstream) of RHEL kernels within a quater of a > year. For Fedora it's only an obstruction, and kernel modules falling > under this category would not even make it into Fedora. > > Don't get me wrong, I'n neither arguing against RHEL, ISVs, closed > source or anything, I'm just showing what the use is for to show that > we can't expect much. > > What you can expect is indeed some limited recycling of kernel modules > of previous kernel/kernel module installations especially on RHEL. But > that's an orthogonal project to packaging them. weak-updates should > check wherever kernel modules of the kernel package and the external > kernel modules is placed and see whether the module is reusable. -- Axel.Thimm at ATrpms.net
Attachment:
pgpVnWMb3mO6h.pgp
Description: PGP signature
-- Fedora-packaging mailing list Fedora-packaging@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-packaging
