Hi,
I should work on kernel rpm for my bachelor thesis. I plan to get
dreamplug and make kernel rpm for kirkwood processors. After that i
can work on other devices.
Peter
On 29 March 2011 21:26, omall...@msu.edu wrote:
Quoting Gordan Bobic gor...@bobich.net:
omall...@msu.edu wrote:
Quoting Gordan Bobic gor...@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
___
arm mailing list
arm@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/arm
--
:wq
___
arm mailing list
arm@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/arm
