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