Am Do, den 24.06.2004 schrieb Jeremy Katz um 16:59: > 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. I thought it worked fine in most situations before. But I also think the basic approach is better now. > It loses some for packagers. Yes. Really. > 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. ++ > > 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. Why can't they also contain the arch-part (i586, i686) like they contain the smp-tag. So they were installable all in parallel. With Suse that is possible. I like that very much. And please don't answer "Yes, but that's ugly to look at :-)" ;-) Yes, I know, for most people this in unimportant. And changing machines i686 and i586 happens not that often. That happened much more often when there was a special athlon kernel... > 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 would really like a solution like that. In fedora.us there ist a package in the QA queue with contains the files from /lib/modules/$(uname -r)/build of all different kernels in /usr/src/. See http://bugzilla.fedora.us/show_bug.cgi?id=1709 > That's just my thinking out loud, though... I'm sure other people have > ideas as well. BTW: IMHO we should also consider if we use the approach (at hole or in parts) that the kernel-developers are working on. See http://www.uwsg.indiana.edu/hypermail/linux/kernel/0406.2/1280.html Arjan also commented in the thread but was not that enthusiastic AFAICS... But I don't what to end in a situation where building external modules is different then the kernel documentation suggest. Or different from all other distributions... Just my 2¢ CU thl
