Hi David,
On 01/28/2010 08:41 PM, David Turner wrote:
On Thu, Jan 28, 2010 at 2:44 AM, Bastien ROUCARIES
<roucaries.bast...@gmail.com <mailto:roucaries.bast...@gmail.com>> wrote:
They use also craps like sdl :S
That's totally orthogonal to upstream QEMU. The code for our
SDL-supported interface is totally separate from the rest
of QEMU changes (or so I hope), and also different from mainline's sdl.c
I think a total rewritte will be better .
How can incremently add a new arch to qemu or a new plateform ?
Depends on what your goal is. If all you want is to be able to run
Android system images in an upstream qemu executable,
you will need essentially the following:
- the content of hw/goldfish_<xxxx>.c in the Android codebase,
corresponding to the emulated hardware
- hw/android_arm.c to be ported to upstream too
- a few changes to the slirp code to setup the default network
redirections
- a few changes to vl.c for setup.
that should be it, though I cannot guarantee success at this point.
Also you will miss many features of the emulator, but
as I already said, this should not be a concern for upstream
maintainers at all.
It would certainly be helpful if you could give us a more detailed list
of the features of the Android emulator. If there are bits that you
currently have that are generally useful, you might find that there is
some interest in pulling those bits in too.
I know you implement an overlay mode for SDL along with the ability to
support buttons in a generic way (I think via XML or something). I
don't think that belongs in QEMU and I think we've discussed this
before. But beyond that, I'm curious what you currently support that we
don't in upstream.
Regards,
Anthony Liguori
