Quoting Gordan Bobic <gordan(a)bobich.net>:
It'd have to be more finely grained than sub-architecture since a
kernel
for one target won't necessarily work on other CPU of the same
sub-architecture (e.g. a Kirkwood kernel won't work on all ARMv5
processors).
Is there a way around this? I mean like being able to make a
megakernal with a ton of modules that has support for every board and
autodetects hardware?
When you look at the defconfigs for arm, you see about 50 of them. It
would be nice to have a "generic" arm, or a generic arm5 configuration
that would be a megakernel with all the hardware in modules or
something that can autodetect the board and proc. Even broken out to
armv5, armv6, etc would be nice.
Then if you want to tweak your kernel for sheeva or OMAP, then by all
means go ahead. Im not even against supplying precompiled kernels for
this but it would be more like a x86 pae, MP or xen kernel.
--
If the split is not hardfp, I would seriously consider looking at
bootstrapping FAT binaries for optimisations between v5 and v7. Im
pretty sure this is how Apple did some of the optimisations for
Altivec for OS X which means some of this code maybe sitting in the
Darwin archives.
(Apple started off by using something similar to the perl script to
relink, with OS 10.0 it took like 20 minute to download and install an
update, and about 3 hours to "optimise", they ended up backgrounding
the process and then they switched to something else which I think is
the bootstrap.)
(the 68k-> PPC fat binaries, actually was two separate binaries of the
program, and the bootstrap just picked which "fork" in HFS to read for
the binary from which you can't do on linux easily.)