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
