[Qemu-devel] Re: Merge qemu android

[Jan Kiszka <jan.kiszka@web.de>]

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

David Turner wrote:
> On Thu, Jan 28, 2010 at 2:44 AM, Bastien ROUCARIES <
> 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

Pushing that bits upstream, converting them to qdev etc. should be a
good plan for whoever wants to make a start - even at the risk of
"forking" from Google's code base. I guess at some point you will be
allowed to adjust your strategy and join that effort simply because
maintaining your own tree became too expensive.

> - a few changes to the slirp code to setup the default network redirections

That sounds strange given that slirp is fairly configurable during
runtime these days. Can you elaborate?

> - 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.

I think upstream would already benefit from having support for booting
images, being able to stimulate most inputs, enabling users to play with
virtual phones and allowing developers to debug (upstream) kernels.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 257 bytes --]