Quoting Gordan Bobic gordan@bobich.net:
omalleys@msu.edu wrote:
Quoting Gordan Bobic gordan@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.
Whether the kernel is modifiable to allow for that, I don't know, but it certainly doesn't seem to be possible to do that with the current vanilla kernel.
I -assume- it is possible, but I don't know for sure either. It would help quite a bit even if it was just forward compatible.
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.
I haven't tested this myself, but I seem to remember somebody here reporting that the typical improvement from optimizing for ARMv7 while sticking with softfp was in the low single figure % numbers. I'm not sure it justifies the effort.
If you can slide neon optimisation in, it would make it worth it for certain programs.
(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.)
IMO the fat binary support should be handled on the compiler level, not post-processing. There's also the issue of dlls - you'd need the dynamic linking to be aware of it too. And you might end up having /lib5s, /lib5h, /lib6s, /lib6h, /lib7s, /lib7h (like we have /lib and /lib64 on x86/x86-64).
Actually i don't think you can mix hard and soft so per system so that has to be a separate release. :P
There should be say a 3-4 char designation for the /lib since say libhnc would be lib hard neon cuda support. Im not sure the H is needed, but the point is more that it needs to be standardized in an extensible format non-confusing format. Like if there was a haploid vector processor, then you dont have a libh for both hard-fp and libh for vector.
All that seems like a lot more effort than maintaining two separate builds, and I cannot think of a reasonable use case where it would be of vital importance to have binary compatibility. Why bother with binary compatibility when you have the source. :)
The issue I see is ARM appears to be moving quite fast right now, and in order to keep up, I don't think it is wise to keep releasing a new distro for every new arch. I just don't think that is a good habit to get into. Or else our distribution ends up to be a mess like the Kernel is.
By having "fat" compatibility, it gives the ability to speed up the 20 packages that you can get significant improvement from, without having the manpower to work out the other 1300. I am guessing the majority of the issues with the distro, are related to the whole ARM arch and not just a subset of the arch.
Also, I see this as a bigger issue moving forward and especially when you start adding vectorization optimisation to the equation and the armv21 "lightning" processor is released.
--
To sound like a hypocrite...
I actually don't have an issue with a build of say armv7 hardfp for F15 especially if the patches are getting pushed upstream, by the time koji gets to F15, I assume 99% of the bugs will be fixed and it will be merely a recompile. :P