[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: qemu/Scratchbox ideas



Hi,

   I did not get this discussion from the beginning, so...
I maintain a ThinClient system that is supposed to run on a x86. Now we have to support ARM as well and I could not still figure out the best way to do so. Ideias?

   I always compile from source and the structure is like this:
   program_name-x.y-original.tar.bz2
   program_name-x.y-i386patches.tar.bz2
   program_name-x.y-i386extra_bin.tar.bz2

So the original gets patched in a tree sources_i386/program_name-x.y, compiled to binaries_i386/program_name-x.y and the extra binaries (images, sounds, customizations, etc) are also sent to this bin dir.

The compilation of an entire system can take a loooong time, so I set a basic image server which mounts a NFS root and I put the thinclients to compile the system themselves. I do this using distcc & ccache. I think that compiling inside an emulated enviroment is not the best choice because you loose a lot of flexibility given by these and a lot of others tools.

Peter Naulls wrote:

This builds on some discussions I've had with Wookey about various build
ideas, and talking with the Scratchbox people.  It doesn't neccessarily
conflict with Stag issues, and in fact it could work alongside it, but
as the details of Stag don't affect this much, I won't mention it any
further.

Part of the problem of Scratchbox for me is that it's so damn big.  I
understand why it is, and what it's trying to achieve by being so.
Fine.   Also, anyone who's played with the recent Debian packages of it
will realise how mature it's become, and how capable qemu is now with
it - you don't really need a native target machine at all.

In fact, and the point of this post, is that you don't actually need SB
at all. It's possible, with the right runes, to chroot into a ARM
filesystem image (e.g a full Debian ARM system), and run stuff.   You
will find you won't get too far however - there are obvious issues with
double word ordering when running perl (e.g installing packages), and
some unimplemented syscalls.  Nevertheless, it's quite impressive that
it can be done at all.

So, where does this leave us?  Well, assmuing that qemu gets fixed
eventually, which seems likely, you could download a relatively small
Debian ARM image (say, 50MB), and cross compile stuff with the only
magic being the emulation of ARM binaries, and none of the other stuff
that SB has to do to wrap things up so they work.   You could easily
pull down new packages if you needed to them to build things.

The downside is speed - all user space is now emulated - especially for
compiling, unlike SB we're running a native compiler, not an x86 cross
compiler running at full host speed.  How much of an issue that would
be would depend upon some benchmarks being done, and the raw speed of
your system.

To mitigate this, one option would be to allow the chroot to install
x86 packages into the ARM chroot.  In particular, you could "just"
install the x86 package of perl, and other packages that might be speed
crucial.  For GCC, you could make a cross compiler that looked just
like a native compiler, except it happened to spit out ARM binaries.

Comments?



--
Eduardo Correia eduardo.correia@poli.usp.br +55(11) 8264-2330/5641-0936
"And from there we emerged to see the stars once more."





Reply to: