Quoting Gordan Bobic <gordan@xxxxxxxxxx>: > 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.) _______________________________________________ arm mailing list arm@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/arm
