No more kernel-source(code) ??? (was: rawhide report: 20040623 changes)

[Jeremy Katz]

On Thu, 2004-06-24 at 10:29 -0400, Jack Neely wrote:
> On Wed, Jun 23, 2004 at 09:43:54PM -0400, Jeremy Katz wrote:
> > On Thu, 2004-06-24 at 02:14 +0200, Axel Thimm wrote:
> > > In theory, yes, but try to build a kernel module for i686 on an athlon
> > > box. The kernel sources will clash with the running kernel.
> > 
> > I'd rather fix this problem than paper over it with the kernel source.
> > Especially since to really do things with the kernel source right now,
> > you have to make changes to the tree in /usr/src.
> > 
> 
> Really, this is the main issue at stake.  Us packagers have been
> building packages of kernel modules for years on 2.4.  There is a
> defined way to use the installed kernel-headers to create modules that
> work with 1586, 1686, athlon, and the SMP variations thereon.
> 
> Now we have 2.6 and the same thing doesn't work and there's lots of
> confusion about how to build external kernel modules.  I know I'm
> confused.

Bingo.  The current situation, though, is far better for a single user
who wants to build a kernel module.  It loses some for packagers.
Coming up with a solution that makes things easy for the user who just
wants to build a module for their running kernel _and_ the person trying
to package modules for a larger audience will be a big win.  

> First, everything you need to build kernel modules is installed with the
> kernel package proper in /lib/modules/`uname -r`.  No kernel source
> package is required.  It just works, try it.

Yep.  Hooray, mkkerneldoth can die :)

> FC2 has an i586 and i686 kernel packages.  The 2.6 kernel is smart
> enough to do the athlon optimizations on the fly, so that's one less
> arch to build for.  SMP modules appear to be identical to non-SMP.
> (From what I've gathered...not sure if there should be a difference
> there or not.)  How do you build for the i586?  I'm not going to remove
> my running kernel to install the i586 arch.  

SMP modules are different from the non-SMP ones, but that's not a
problem as you can install kernel-smp in parallel with your main kernel
package.  The i586 vs i686 part is the hard one.

Personally, I think that having a kernel-devel package that puts the
headers somewhere with both the `uname -r` and arch as part of the path
would be useful.  That ends up working very nicely for people doing
packaging.  Unfortunately, it goes back to making things more difficult
for an end-user.  The best thing I've come up with at present for that
is to continue to do like is being done now (headers for the current
kernel in /lib/modules/$(uname -r)/build) and have kernel-devel be in
addition to that.  It would be a little bit higher disk space usage, but
as kernel-headers would only need to be installed for special cases, I'm
not sure that's a huge concern.  Actually, I guess that /lib/modules/
$(uname -r)/build could be a symlink to /usr/include/kernel-headers/
$(uname -r)/$arch and be included as a broken symlink in the package.
That _might_ work for keeping both camps happy.

That's just my thinking out loud, though...  I'm sure other people have
ideas as well.

Jeremy