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

[Jack Neely]

On Thu, Jun 24, 2004 at 10:59:31AM -0400, Jeremy Katz wrote:
> 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.

I was thinking something on the lines of a kernel-devel package anyway.
That would also solve the it takes to long to install the kernel
package.  This stuff is only needed when building things for the kernel
and every other package would use a -devel subpackage.

Thoughts?

Jack


> 
> That's just my thinking out loud, though...  I'm sure other people have
> ideas as well.
> 
> Jeremy
> 
> 
> -- 
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> http://www.redhat.com/mailman/listinfo/fedora-devel-list
> 

-- 
Jack Neely <slack at quackmaster.net>
Realm Linux Administration and Development
PAMS Computer Operations at NC State University
GPG Fingerprint: 1917 5AC1 E828 9337 7AA4  EA6B 213B 765F 3B6A 5B89