Hi folks,
I'm working on some to-be-proposed updates to the kernel module packaging in Fedora Extras to allow us to track changes to the kernel ABI rather than purely the kernel release/version. This should make life easier and help to reduce the number of times that a minor kernel update (e.g. security fixes, etc.) forces all external drivers to be rebuilt.
At http://www.kerneldrivers.org/ I have some sample packages that I'm working on, as well as a description of the process and how this relates to other Linux distributions, such as SuSE.
I'm going to continue working on this, keep the wiki updated, and ultimately ask FESCo pretty soon if we can make a few minor changes to kmodtool and get this out there. Obviously, I'm very keen to hear from anyone else who wants to help :-)
Thanks!
Jon.
On Sat, 2006-06-03 at 01:47 +0100, Jon Masters wrote:
Hi folks,
I'm working on some to-be-proposed updates to the kernel module packaging in Fedora Extras to allow us to track changes to the kernel ABI rather than purely the kernel release/version. This should make life easier and help to reduce the number of times that a minor kernel update (e.g. security fixes, etc.) forces all external drivers to be rebuilt.
I'm not so sure this will work for Fedora. The ABI in the kernel is utterly inconsistent, and no work is being done upstream to try and keep the ABI consistent or predictable.
In fact, in the majority of cases, a kernel module built against one kernel release/version will only work against that release/version. Effectively, the only ABI we can control in Fedora is the one for that kernel release/version.
Now, RHEL is different, but these guidelines are Fedora specific.
~spot
On Sat, Jun 03, 2006 at 09:06:42AM -0500, Tom 'spot' Callaway wrote:
On Sat, 2006-06-03 at 01:47 +0100, Jon Masters wrote:
Hi folks,
I'm working on some to-be-proposed updates to the kernel module packaging in Fedora Extras to allow us to track changes to the kernel ABI rather than purely the kernel release/version. This should make life easier and help to reduce the number of times that a minor kernel update (e.g. security fixes, etc.) forces all external drivers to be rebuilt.
I'm not so sure this will work for Fedora. The ABI in the kernel is utterly inconsistent, and no work is being done upstream to try and keep the ABI consistent or predictable.
I'd go as far as to say for Fedora, there *is no* kernel ABI, nor is it practical to make one.
Dave
On Sat, Jun 03, 2006 at 13:01:22 -0400, Dave Jones wrote:
On Sat, Jun 03, 2006 at 09:06:42AM -0500, Tom 'spot' Callaway wrote:
On Sat, 2006-06-03 at 01:47 +0100, Jon Masters wrote:
I'm working on some to-be-proposed updates to the kernel module packaging in Fedora Extras to allow us to track changes to the kernel ABI rather than purely the kernel release/version. This should make life easier and help to reduce the number of times that a minor kernel update (e.g. security fixes, etc.) forces all external drivers to be rebuilt.
I'm not so sure this will work for Fedora. The ABI in the kernel is utterly inconsistent, and no work is being done upstream to try and keep the ABI consistent or predictable.
Sure. I understand. I guess what I'm saying is "look, you get this for free, it requires no extra effort on the part of the packager, but it may help reduce unnecessary updates". I understand the lack of a kernel ABI in Fedora - whenever part of the ABI changes, the module just becomes incompatible in its dependencies and you upgrade it in the usual way.
I'd go as far as to say for Fedora, there *is no* kernel ABI, nor is it practical to make one.
:-)
Ok. Well, given that it doesn't hurt packagers or make their lives more difficult - isn't it worth making this available to them anyway? I'm cool with whatever the Fedora community want.
Jon.
P.S. This mail was hand munged via the archives, so it's going to break threading - for some reason I'm not getting fedora-packaging delivered directly right now even though I'm signed up. Will investigate.
On Mon, 2006-06-05 at 13:29 +0100, Jon Masters wrote:
Ok. Well, given that it doesn't hurt packagers or make their lives more difficult - isn't it worth making this available to them anyway? I'm cool with whatever the Fedora community want.
The problem is this:
By documenting it as part of our standards, we're implying that it is something with benefit to the packagers. Since there is no kernel ABI in Fedora or upstream (remember, all kernel ABIs in RHEL are artificial constructs), it does hurt packagers who are unaware of this fact. It leads them to believe that they don't need to use the full Requires: %{version}-%{release} in kernel-module addon packages, when they absolutely do.
~spot
On 6/5/06, Tom 'spot' Callaway tcallawa@redhat.com wrote:
By documenting it as part of our standards, we're implying that it is something with benefit to the packagers. Since there is no kernel ABI in Fedora or upstream (remember, all kernel ABIs in RHEL are artificial constructs), it does hurt packagers who are unaware of this fact. It leads them to believe that they don't need to use the full Requires: %{version}-%{release} in kernel-module addon packages, when they absolutely do.
Well, they wouldn't necessarily include that Requires line, because the kernel dependency is now against a set of binary checksums that determine compatibility.
In fact, I'm not really calling for major packaging changes - by making a few changes to kmodtool behind the scenes, all of this is abstracted from the packager, who is free to demand a specific kernel or just let the dependency resolution figure out if the kernel and module will be compatible at RPM install time. The only issue really is how this would affect official "policy" with regards to kernel dependencies as you hinted at above.
Jon.
On Mon, 2006-06-05 at 14:10 +0100, Jon Masters wrote:
On 6/5/06, Tom 'spot' Callaway tcallawa@redhat.com wrote:
By documenting it as part of our standards, we're implying that it is something with benefit to the packagers. Since there is no kernel ABI in Fedora or upstream (remember, all kernel ABIs in RHEL are artificial constructs), it does hurt packagers who are unaware of this fact. It leads them to believe that they don't need to use the full Requires: %{version}-%{release} in kernel-module addon packages, when they absolutely do.
Well, they wouldn't necessarily include that Requires line, because the kernel dependency is now against a set of binary checksums that determine compatibility.
These binary checksums will change with every single kernel release/variant. I'm not sure I see the point of using an always unique binary checksum vs a %{version}-%{release}?
In fact, I'm not really calling for major packaging changes - by making a few changes to kmodtool behind the scenes, all of this is abstracted from the packager, who is free to demand a specific kernel or just let the dependency resolution figure out if the kernel and module will be compatible at RPM install time. The only issue really is how this would affect official "policy" with regards to kernel dependencies as you hinted at above.
If kmodtool starts providing this by default, then there would be no need for the Requires: v-r in the policy. I suspect you'd need to convince the kmodtool author(s), not me. :)
~spot
On 6/5/06, Tom 'spot' Callaway tcallawa@redhat.com wrote:
In fact, I'm not really calling for major packaging changes - by making a few changes to kmodtool behind the scenes, all of this is abstracted from the packager, who is free to demand a specific kernel or just let the dependency resolution figure out if the kernel and module will be compatible at RPM install time. The only issue really is how this would affect official "policy" with regards to kernel dependencies as you hinted at above.
If kmodtool starts providing this by default, then there would be no need for the Requires: v-r in the policy. I suspect you'd need to convince the kmodtool author(s), not me. :)
That's what I'm trying to do at the moment :-)
With that done, there's no need to make user-visible changes to the packaging process at this stage, except that we can introduce a >= type dependency on the base kernel release if it's felt that a kernel version should be included in addition to the binary dependency information.
To check out what I mean, take a rawhide kernel and do:
rpm -q --provides kernel
on it. You'll see a set of dependencies, one per directory of the kernel source used to build that kernel. For example kernel(kernel) = blah means that the checksum for built-ins in the /kernel subdirectory is blah. This is then matched against in the dependencies of the module.
Part 2. I've also spoken to the SuSE folks about agreeing on a joint packaging standard for driver updates that could be used in Fedora, OpenSUSE and potentially in commercial products at a later stage. There's a channel for communication there so I want to explore that in the longer term - having a common set of RPM macros that encapsulate our differences and present a single spec file format. I don't know if you folks will love or hate that idea :-)
Jon.
packaging@lists.fedoraproject.org
-
Dave Jones -
Jon Masters -
Tom Callaway