Re: qemu/Scratchbox ideas
Justin Cormack <email@example.com> :
> On Tue, 2004-05-04 at 14:48, 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.
> Actually for various reasons I rather like this idea. I like the idea of
> having what basically looks like a native compile environment, without
> any cross stuff at all.
> The only problem is compile speeds, as emulating gcc is going to be slow
> (how slow is it?). The obvious answer is to install distcc becasue that
> enables you to use cross compilers anyway on the remote machine(s).
Maybe a good idea for the emdebian project is to build some kind of
cluster with a lot of CPU power to emulate Qemu with a kind of
scratchbox to have a reference chrooted env.
I don't know where we can find such cluster...
Benjamin Henrion <firstname.lastname@example.org>
<<< Push the Parliament democracy against Commission-Council Terrorism >>>
<<< Promoting Abuses of the Patent System is Juridical Terrorism >>>
<<< http://swpat.ffii.org >>>