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
Attachment:
pgpYOfFJDS4ke.pgp
Description: PGP signature
-- Fedora-packaging mailing list Fedora-packaging@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-packaging
