On Monday 14 August 2006 14:06, Thorsten Leemhuis wrote: > Yum will install: > kmod-foo-1.3.2.6.17-1.2171_FC5 > *and remove* > kmod-foo-1.2.2.6.17-1.2157_FC5 > kmod-foo-1.2.2.6.17-1.2171_FC5 > in the same transaction because the module location of > kmod-foo-1.2.2.6.17-1.2171_FC5 and kmod-foo-1.3.2.6.17-1.2171_FC5 would > conflict. *This remove is the problem Axel complains about.* I could see it removing kmod-foo-1.2.2.6.17-1.2171_FC5, but why does it also remove kmod-foo-1.2.2.6.17-1.2157_FC5? Wouldn't that be in a different module tree?

> == Proposed solution == > > Install the kernel-module to > > /lib/modules/kabi/MODULE/VERSION-RELEASE/{MODULES...}.ko > > and remove the > > "Requires: kernel<?kernel-flavour>-<?kernel-version> > > Details: > > We avoid the file conflicts noted in "Problem" above due to the > "VERSION-RELEASE" in the path. So yum will always install the module and > there won't be any conflicts. > > But how will the kernel find the module there? "/sbin/weak-modules", the > script from the kabi stuff can create links to the proper places. It > does this already for modules installed in the proper place and kernels > that have the compatible kabi. It would be needed to adjust some > pathnames in the script, but that shouldn't be to hard. > > And why remove the Requires? Well, with the kabi stuff it might happen > (not that often in Fedora, but on RHEL often) that a module runs fine on > a newer kernel. We wouldn't have to build a new module in that case. > *But* this requires would fire back because the kmod will get removed by > the depsolver when the kernel is was build for gets uninstalled. > Therefor it needs to be removed. Also, with the kabi stuff, the Requires should get done automatically to an ABI version. If the next kernel has an ABI change, and you rebuild the module, thats cool, it picks up the new ABI in the automatic Requires. No manual intervention.

I would _really_ like to get JCM involved in this discussion, especially on the proper place to drop these modules so that a respin for one kernel won't remove modules from an older kernel.

> Well, normally it's a "install transaction" but when there is a > potential file conflict it's changed to a "upgrade transaction" afaik -- > and that will remove the old kmod as well because both old kmods have > the same packagename. This is not correct.  The current implentation will install the new module and add an erase transaction element for the old module requiring the same kernel.  

On Monday 14 August 2006 16:11, Jack Neely wrote: > > Well, normally it's a "install transaction" but when there is a > > potential file conflict it's changed to a "upgrade transaction" afaik -- > > and that will remove the old kmod as well because both old kmods have > > the same packagename. > > This is not correct.  The current implentation will install the new > module and add an erase transaction element for the old module requiring > the same kernel.   Wait, stop the presses. Isn't this the "root" of the problem that Axel is complaining about, that the kmod version of doing things will cause old modules for old kernels to get removed? If this isn't the case, then why are we talking about replacing the current standard?

== Remaining problem == When do old kmods get removed from the system? Yes, that's a remaining problem (that's why it's listed here (-; ). I'll talk to jcmasters and jeremy and will work out a solution if we agree to work further on this idea. I'm sure we'll find a solution. The installonlyn-plugin maybe could handle that together with the kabi stuff. weak-modules could mark a installed module as unused and the plugin (or another plugin) could remove it later.

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.

You need to encode evr into the path and then teach depmod or any helper application to order according to rpm's evr scheme.

It's not an improvement, it's outsourcing a packaging/versioning problem to the wrong domain.

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.