[Fedora-packaging] Re: get further rid of uname -r in the kmod stuff and solve the remaining kmod problem

[Axel Thimm]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-packaging/attachments/20060815/572cb710/attachment.sig>