Bug 145914 - Use uname in kernel-devel directories
Summary: Use uname in kernel-devel directories
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Rik van Riel
QA Contact:
Keywords: EasyFix, Patch
Depends On:
Blocks: FC4Target
TreeView+ depends on / blocked
Reported: 2005-01-23 21:16 UTC by Ville Skyttä
Modified: 2014-01-21 22:51 UTC (History)
10 users (show)

Clone Of:
Last Closed: 2005-04-03 21:20:23 UTC

Attachments (Terms of Use)
Use uname as-is in kernel-devel directories (1.52 KB, patch)
2005-01-23 21:16 UTC, Ville Skyttä
no flags Details | Diff
Use uname as-is in kernel-devel directories, rev 2 (1.56 KB, patch)
2005-03-28 20:15 UTC, Ville Skyttä
no flags Details | Diff

Description Ville Skyttä 2005-01-23 21:16:47 UTC
The current kernel-devel packages seem to be mostly fine for building external
module packages.

However, there's one flaw: the directories below /usr/src/kernels do not contain
the exact uname of the target kernel, for example

The problem is the extra hyphen between the "base uname" and the variant, "smp"
in this case.

Removing that hyphen and providing an exact uname would ease the task of finding
the correct directory for kernel $uname, since that could be used as-is without
having to resort to homebrew solutions and special casing non-UP kernels.  "Want
to build for kernel with uname XYZsmpfoo, arch i686?  Point your build process
at /usr/src/kernels/XYZsmpfoo-i686." would Just Work(tm).  It would also be
analoguous and consistent with everything else kernel related stuff, like
/boot/vmlinuz-$uname, /boot/config-$uname, /lib/modules/$uname etc.

With the finite set of kernel variants provided by Red Hat, the problem isn't
disastrous, but it is a bad one when working with custom kernels.  Every module
package would have to know all possible variants of target kernels; that is not
a solvable equation.

So, this:


...should become:


...ie more generally, /usr/src/kernels/$uname-$arch, not

Suggested patch attached, *please* consider making this change before any
kernel-devel packages are released outside Rawhide.  I was not able to test the
patch because the kernel is not currently buildable from my CVS checkout, but I
expect the patch to work.

Comment 1 Ville Skyttä 2005-01-23 21:16:47 UTC
Created attachment 110109 [details]
Use uname as-is in kernel-devel directories

Comment 3 Ville Skyttä 2005-01-29 12:41:58 UTC

Comment 4 David Woodhouse 2005-01-30 18:57:43 UTC
But surely uname is only useful for the _current_ kernel, and you can
find the build tree for that in /lib/modules/`uname -r`/build as always.

For other kernels than the currently running one you need a different
solution anyway.

Comment 5 Ville Skyttä 2005-01-30 19:12:47 UTC
/lib/modules/`uname -r`/build is not sufficient, because it is not
arch-qualified, ie. it does not contain "i686" etc.  See bug 143160.

uname is useful for others than the current kernel.  For example, the
"standard" way of building for a specific uname kernel and arch for
many 3rd party module packagers has been something like:

  rpmbuild -bb --target i686 --define 'kernel 2.6.10-1.741_FC3smp'

...and in the specfile, one can add:

  Requires: /path/to/%{kernel}-%{_target_cpu}

...assuming the kernel source tree lives at
/path/to/2.6.10-1.741_FC3smp-i686, and point the build process at
that.  Problem solved: proper rpm build dependency in place, and a
directory to point the build at.

With the current kernel-devel packages, one would have to place some
magic into every kernel module specfile for resolving an
arch-qualified directory for uname $uname, which is caused by the
extra hyphen between the "base uname" and the variant as outlined in
the intial comment.

Of course, this is just one way to solve the problem.  If you have
other suggestions that meet the requirements (must be able to specify
something uname and arch qualified in a reliable way), those would be
appreciated.  I believe what I suggest is the least intrusive one
though, when both kernel and the myriad of module packages out there
are considered.

Comment 6 Ville Skyttä 2005-02-04 23:19:58 UTC
Nominating for FC4 as test1 is coming closer.
Any news to share here?

Getting this fixed would allow us to modify the Extras
kernel-module-devel package for compatibility with kernel-devel, as
well as start writing basic kernel module packaging docs for Extras.

I'd be happy to provide more info, just ask if more is needed.

The kernel-devel packages in Rawhide are _so_ close to being _really_
useful and easy to use that it's painful to see this last bug (*knocks
wood*) standing as FC4 is closer every day... :/

Comment 7 Thorsten Leemhuis 2005-02-05 12:09:11 UTC
David (and Dave), I'm also involved packaging kernel modules for
extras and another major repo. This additional "-" makes writing
spec-files way harder for no good reason I can see. 

Ville gave very good reasons why this should be changed -- I don't
want to repeat them, they are all valid from my point also. So do you
refuse to drop it? Did you use this scheme in RHEL4 and now want to
stick with it in Fedora? 

Comment 8 David Woodhouse 2005-02-05 12:22:49 UTC
Certainly it would make more sense to have done it that way, I agree.

I need to investigate this 'standard' way of building external
modules, and understand why it can't cope. We also need to consider
the implications for compatibility with RHEL4, but I don't really see
that's too much of an issue.

I plan to look at it shortly when certain other things are out of the
way. I haven't been looking at the FC4 kernel at all recently. It
doesn't even boot on PPC -- what's the point? :)

Comment 9 Ville Skyttä 2005-02-05 13:57:30 UTC
Thank you.  At the risk of being overly verbose again: the basic
problem boils to this:

Given an arbitrary kernel "uname -r" and arch, it is not possible to
derive the arch-qualified source directory from them without
additionally making assumptions on what part of the uname is the
variant.  For current Rawhide kernels, the variant set {smp,xen0,xenU}
as the assumption would work, but that is not enough for non-FC,
custom kernels.

Let's say I build custom kernels based on the FC ones, and implement
them as a "variant", just like Red Hat does (smp,xen0,xenU).  The
packages are named eg. kernel-vs-2.6.10-1.760_FC3, and the "uname -r"
will be 2.6.10-1.760_FC3vs.  Now, to derive the source dir, module
packages would need to know that an extra "-" needs to be added
between "FC3" and "vs" to find the arch-qualified source dir.  I see
no way they can do this reliably without having the "vs" added to
their list of known variants.

I guess it is possible to reliably derive the corresponding "uname -r"
from a given source directory containing the extra "-" without making
too many (if any) assumptions,  but I'm afraid that does not help.

Is kernel-devel already implemented in RHEL4 with the extra "-" in the
dir name?  If yes, is it already frozen wrt. this?

Comment 10 David Woodhouse 2005-02-05 14:40:06 UTC
My concern is that you're _not_ given 'uname -r'. You actually have to
piece that together for yourself _anyway, surely?

If you want to build a full set of kernel modules for Fedora Extras,
for example, surely the best thing you have to go on is the set of
kernel-*-2.6.10-* binary RPMS? And that nomenclature is different _again_.

We need to consider this from the point of view of a simple script
which can build modules for a full set of kernels, and I don't see how
the output of 'uname -r' is relevant to that.

Am I missing something?

Comment 11 David Woodhouse 2005-02-05 14:57:05 UTC
fish /home/dwmw2 $ cat asd
fish /home/dwmw2 $ cat asd | sed

Comment 12 Ville Skyttä 2005-02-05 15:45:52 UTC
This is good food for thought, thanks.  Will play around with it a bit
and follow up later, but it might take until tomorrow.

Comment 13 Ville Skyttä 2005-02-06 18:51:30 UTC
Ok, it is possible to use the kernel-*-devel packages as they
currently are in Rawhide.  But my request for changing the source dirs
to use "uname -r" still holds.  If compatibility is a concern, the
hyphenless ones could be included as owned symlinks.

See http://koti.welho.com/vskytta/kmods/
kmods.txt contains various requirements and use cases for kernel
module and -devel packages, and the two specfiles implement these use

kmodtest-with-uname.spec uses the "uname -r" approach and assumes that
the "extra hyphen" as outlined earlier here is gone from the source
dir's name.

kmodtest-with-nvr.spec uses a name-version-release approach and
assumes that the kernel-devel source dir names will stay as they are
currently in Rawhide.

So, both are doable, but I have no doubt which approach would be
better in terms of... uh, well, everything :)  The only case where the
"nvr" approach "wins" is case 4, and even there, very slightly.  I am
not convinced if that case is actually too real-world-relevant.

You should be able to experiment with the specfiles using "rpmbuild
-bp --nodeps", and watching the output.  See kmods.txt for examples.

Comment 14 Ville Skyttä 2005-02-13 20:43:56 UTC
Setting DEFERRED after discussing this with David in PM.

To summarize: it's not clear that using "uname -r" is The Ultimate Correct Way
in the first place, it's just one possible approach.  Making changes now would
be possibly incompatible with RHEL4 which we surely don't want without a good
reason.  And adding compatibility symlinks doesn't necessarily make sense
either, as there's not really anything "standard" out there to be compatible
with (no, I don't consider fedora.us kernel-module-devel really _that_ standard).

Additionally, there are things that clearly _are_ bugs that need work out there
(eg. bug 147553, and how module packages should be arranged so that they're
buildable with the Extras buildsys when it's available), better to spend time on
that stuff first, and revisit this issue later if need be.

BTW; I have a new version of fedora.us kernel-module-devel available that makes
it forwards compatible with kernel-devel in Rawhide.  If someone wants to try it
out, mail me.

Comment 15 Ville Skyttä 2005-03-28 20:15:42 UTC
Created attachment 112398 [details]
Use uname as-is in kernel-devel directories, rev 2

Here's a new version of the patch, this one would preserve backwards
compatibility.	Untested, "should work", I've never managed to build the kernel
packages from CVS...

Comment 16 Rik van Riel 2005-03-29 19:33:46 UTC
I've applied Ville's patch as-is.  It should be in the next rawhide kernel.

Comment 17 Ville Skyttä 2005-04-03 21:20:23 UTC
Works for me, thanks.

Note You need to log in before you can comment on or make changes to this bug.