[haiku-development] Re: FatELF on Haiku?

> You seem to miss the point, allow me to explain my argument. Since you
> referred to ARM (I can't speak for 68k), ARM cpus suffer much more
> fragmentation than all other cpu lines (like x86 or even PowerPC). As it is,
> ARM has Thumb, Thumb2, NEON, VFP, iwMMXt, ARM5, ARM7, ARM9, ARM11,
> ARM9+media array (in the case of zms-05 by Zii Labs), etc. What might
> provide top performance on one CPU model might be totally unsupported by
> others, or if supported it might make the cpu totally sluggish. For one
> thing, ARMv5 code underperforms on later cpu models like ARM9 or ARM11 -the
> exact technical details evade me- and it would be nice to have
> well-performing versions for all chips. If not, we'd be a) need several
> haiku versions/distros for each ARM family, b) support just the base ARM
> code, but missing all the features like NEON eg. or c) provide an ultra
> optimised version for one family -eg. Cortex-A8- but all other ARM users
> would be complaining and missing out all the fun.

We definitely don't want to support all of them. And FatELF is not
needed to do so anyway. Look at mplayer under linux : at runtime it
will detect CPU abilities and replace some parts of the code
(time-critical sections) with optimized ones. There is no need to
duplicate the whole code in a FatELF binary.

And if you strip it in the end, why would you download all the
versions in the first place ?

It sure was a convenient solution for Mac OS X transition from PPC to
x86, but note they removed all ppc support _before_ switching to x64,
in order not to have 3 archs at the same time. They can have binary
twice as big as needed, but not 3x... In the long term it's not a good
solution. Things like LLVM, with JIT compiling for the local CPU, are
better solutions for this kind of things...

>
> A FatELF-based solution sure it has its problems, but esp. in ARM's case it
> just makes sense. As for disk space, well that's easily solved. A simple
> tool could be run to "strip" useless/unneeded  versions from the binaries.
> The problem is distribution/maintainance of the whole set of binaries, not
> the disk space in the end device. In the one case you have multiple versions
> of the file shipped -btw, how do you expect the user will know the right
> version for his netbook? In the second case, you have one binary, one
> "distro" and a tool to strip the binaries. I don't know about you, but I
> know which option I would choose.

Once you strip it, you can't share it with other people anymore. This
is one of the things I find stupid in the linux world : free software
is supposed to allow you to share your software with any people, and
once you try so, it does not work because of stupid binary
compatibility problems and library versions...

Disk space is not a problem when you have a 500GB hard disk on a PC.
But an ARM device may be some embedded things with less than 1GB of
disk, and you don't want to waste space... There are other, cleaner
ways to solve it, like a package manager knowing the infos about the
hardware, or downloading a small installer that you run and determines
the best binary for your CPU.

-- 
Adrien Destugues / PulkoMandy
Elève ingénieur ENSSAT EII1- www.enssat.fr
GSoC student for Haiku - http://haiku-os.org
GrafX2 project team - http://code.google.com/p/grafx2

Other related posts: