Re: [Qemu-devel] Merge qemu android

[Anthony Liguori <anthony@codemonkey.ws>]

[-- Attachment #1: Type: text/plain, Size: 1802 bytes --]

Hi David,

On 01/28/2010 08:41 PM, David Turner wrote:
> On Thu, Jan 28, 2010 at 2:44 AM, Bastien ROUCARIES 
> <roucaries.bastien@gmail.com <mailto:roucaries.bastien@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

[-- Attachment #2: Type: text/html, Size: 3278 bytes --]