[Fedora-packaging] Re: kmdl proposal and kmod flaws

[Axel Thimm]

On Thu, Aug 10, 2006 at 10:47:12AM +0200, Thorsten Leemhuis wrote:
> together with the kabi stuff and/or with a proper plugin. 

> BTW, do we really want to use the "uname -r" again in times where RHEL 
> will have a kabi which means that the "uname -r" is mostly meaningless? 
> I'd really prefer one solution for both FC and RHEL.

Just to make sure everybody understands about kabi myths and doesn't
have expectations that are known to not be fulfilled:

o There is never ever going to be an ordered api id like kabi = 1.0
o There is no intention of upstream having a stable api which is a
  prerequisite for a stable abi, in fact it is considered a feature
  (less `locate stable_api_nonsense.txt`)
o The discussion about recycling old kernel modules using kabi tools
  means hashing subset information like kabihash(subsystem_abc_def) =
  0ed3425d.
o The full kabi will be a large set of unorderable hases as above
o You don't know from a packging POV which hashes are relevant. And
  even if you knew you would have to concatenate the relevant parts
  into the kernel module package's filename
o If you consider hashing the hashes into one master (sub-)"kabi" hash
  item you will
  - still need the single hashes in the package relations for the kabi
    recycling mechanism to work at all
  - end with an unorderable hash

At the very best you would replace uname-r with an unorderable hash
which no user can associate to his kernel. E.g. with either scheme can
you humanly identify that

foo-kmdl-0ed3425d-1.2.3-4.i686.rpm (or kmod-foo-1.2.3-4_0ed3425d)

can satisfy kabi relationships of

kernel-2.6.18-23.0.1.EL5.i686.rpm and
kernel-2.6.18-23.0.2.EL5.i686.rpm

No, you can't. In a pure RHEL5 world with a really stable kabi (note
on passing that this is *not* the case with RHEL4 and for example the
wireless extensions update breaking both api and abi) you would end up
with dropping the evr of the kernel, e.g. uname -r or kabi, to make
any positive packaging use of the kabi scheme.

In the world of Fedora Core you will never have the same total kabi
hash as the previous kernel, so in this case the discussion is moot
anyway.

So then you may wonder, were's the kabi stuff going to help at all and
why do people invest time to develop it further?

It will only help in RHEL5 and similar "enterprise" environments if
the kernel packages really keep the set of kabi hashes invariant over
the years (and the kabi tools will assist kernel engineering in
detecting and avoiding such changes). The benefits lie with the
IHV/ISVs, who will be able to invest once in a package (either open or
closed source) and never have to rebuild it again for RHEL5 if
engineering does its work well.

It's of no use to systems that don't firmly commit to a stable
kabi/kapi like the upstream kernel itself and Fedora, though. And it
will also encourage use of closed source drivers (see
stable_api_nonsense.txt for why this is so).
-- 
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://lists.fedoraproject.org/pipermail/packaging/attachments/20060810/16b1fb63/attachment.bin