Quoting Gordan Bobic <gordan(a)bobich.net>:
omalleys(a)msu.edu wrote:
> 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.
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