[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

[Fedora-packaging] Re: atrpms kernel modules

On Sun, Jul 23, 2006 at 12:12:58PM -0400, Jesse Keating wrote:
> On Sunday 23 July 2006 11:57, Axel Thimm wrote:
> > 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.
> There are kernel updates for new rebase, there are kernel updates for 
> security, there are kernel updates for specific bug fixes.  There are a lot 
> of cases where the ABI would not change for particular drivers.  SCSI, Video, 
> yes even wireless.  Any naming scheme that will be discussed should take the 
> KABI system into account and use that.  Even if the ABI changes just as 
> frequently as kernel version we should still use the ABI so that the same 
> naming and packaging scheme will work across Fedora Core current releases, 
> maint releases (Legacy), and RHEL (and rebuilds) releases.

Well, add to the above that the kABI isn't going to give you an
orderable single entry like uname-r does (but maybe noone cares, the
kernel module packaging at least wouldn't), and that no user will
understand the mapping between his kernel, whose uname -r he knows,
and a kABI checksum.

But in principle if one day kABI checksums gain a popularity/visibilty
like uname-r has today on the user's side, then I agree, that uname-r
in the name could be replaced with a kABI checksum. In the kmdl scheme
this would be a rather trivial change.

But you're not going to make friends with people already losing lunch
on embedding uname-r in the name. :)
Axel.Thimm at ATrpms.net

Attachment: pgpojrrrvg68w.pgp
Description: PGP signature

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]