On Sat, Jul 22, 2006 at 09:45:51AM -0400, Jesse Keating wrote: > On Friday 21 July 2006 14:35, Axel Thimm wrote: > > I really thing there is a flaw and the uname-r-in-name is the only way > > out, and I'd try to persuade people about that. Maybe they could be > > poited to this mail thread as well, as everything is in principle layed > > out here. > > With the kabi stuff coming along, there is no longer a need to lock a given > module to a given kernel version, just an ABI version. The kernel could > easily be bumped a version but the ABI that a particular module needs would > remain unchanged, and thus the module will continue to work. Locking to a > uname will be pointless at this point. > > Jon Masters is giving (gave?) a talk about this at OLS and was discussing > these things at the kernel summit I do believe. I strongly feel we wait for > him to return from OLS so that we can include him in the discussion > surrounding packaging of external kernel modules. > > As it stands, the development kernel does automatically provide an ABI > checksum for each module subdirectory, and rpm knows about it. Requires on > an ABI supposedly works today. kABI will not really help, as it only measures what has changed in the ABI from on kernel release to the next, checking to see whether an old kernel module can be safely recycled. It will not magically force kernel developers to introduce a stable ABI, function signatures and other symbols will change just as frequent. And the areas where kABI would help is where the kernel has reached some level of maturity where indeed the ABI has become stable. But these are not the typical subsystems external kernel modules are built for. Currenlty the most frequent cases of kernel modules are such usually requiring v4l2, ieee82011 or vm subsystems. And these are currently guaranteed to change from kernel release to kernel release. And once these stabilize and other areas of the kernel become interesting you'll have the same situation there. Currently (the last 1-2 years) every kernel release breaks 70-80% of external kernel modules at build level already, and kABI would only confirm this. So what is really needed is a kernel developers' committment to stabilize the kernel ABI, and we are really far away from such a point in time. And even if that were tomorrow, we need to consider legacy support for a couple of FC releases and also RHEL for a couple of years more. But kABI is definitely the way towards a stable kernel ABI, just not within the timeframe we are interested in, e.g. <= 2 years. So for the current discussion this won't help us further. -- Axel.Thimm at ATrpms.net
Attachment:
pgpAfZKmIQ3Zp.pgp
Description: PGP signature
-- Fedora-packaging mailing list Fedora-packaging@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-packaging
