Re: [Qemu-devel] New emulator code base (qemu-android) and "ranchu" virtual board.

Re: [Qemu-devel] New emulator code base (qemu-android) and "ranchu" virtual board.

[Christopher Covington]

Hi,

[snip--for full message see
https://groups.google.com/d/msg/android-emulator-dev/dltBnUW_HzU/2tSZNLaVzmQJ]

> 5) Relationship with upstream
> 
> In an ideal world, we would not need a fork, and all code would live on
> the upstream QEMU git.
> 
> In reality, things are different: there is little chance that the upstream 
> team would want to maintain 100K+ lines of code that are completely 
> specific to Android, and for good reason. That's why the refactoring effort
> is so important, we need to find a way to maintain the Android-specific
> QEMU patches as small as possible, and push as much stuff into the
> android-emulation library.

I'm curious, have there been previous discussions with the QEMU maintainers
that you can summarize or point me to?

> Even with smaller changes, it's crucial to have a good set of tests, that 
> exercise these Android-specific features, added to the QEMU test suite, and
> clear documentation about the implementation being added. This may require
> a stub or minimal mock version of android-emulation.
> 
> Finally, we may want to dedicate serious engineering resources to better 
> continuous integration of upstream QEMU that would also exercise the 
> Android bits.
> 
> Until we reach such a situation, we will have to maintain a separate fork 
> and continue to rebase it on top of recent QEMU changes.

Thanks,
Cov

-- 
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [Qemu-devel] New emulator code base (qemu-android) and "ranchu" virtual board.

[Alex Bennée]

Christopher Covington <cov@codeaurora.org> writes:
> Hi,
>
> [snip--for full message see
> https://groups.google.com/d/msg/android-emulator-dev/dltBnUW_HzU/2tSZNLaVzmQJ]
>
>> 5) Relationship with upstream
>> 
>> In an ideal world, we would not need a fork, and all code would live on
>> the upstream QEMU git.
>> 
>> In reality, things are different: there is little chance that the upstream 
>> team would want to maintain 100K+ lines of code that are completely 
>> specific to Android, and for good reason. That's why the refactoring effort
>> is so important, we need to find a way to maintain the Android-specific
>> QEMU patches as small as possible, and push as much stuff into the
>> android-emulation library.
>
> I'm curious, have there been previous discussions with the QEMU maintainers
> that you can summarize or point me to?

Taking my Linaro hat off and certainly not speaking for Google or the
maintainers:

Whenever new functionality is added to QEMU we rely on having:

 * Someone to maintain and support the code
 * Interested users that can regularly test and report breakages

Without this functionality can bitrot without being noticed and impose
an additional maintenance burden on the rest of the code-base. The
original authors may well have different priorities (e.g. shipping product!).
Of course not working directly upstream does impose additional costs
in the long term as you either take on the maintenance burden of
backporting fixes to your older tree or fixing conflicts on re-basing
with the upstream.

>> Even with smaller changes, it's crucial to have a good set of tests, that 
>> exercise these Android-specific features, added to the QEMU test suite, and
>> clear documentation about the implementation being added. This may require
>> a stub or minimal mock version of android-emulation.
>> 
>> Finally, we may want to dedicate serious engineering resources to better 
>> continuous integration of upstream QEMU that would also exercise the 
>> Android bits.
>> 
>> Until we reach such a situation, we will have to maintain a separate fork 
>> and continue to rebase it on top of recent QEMU changes.

Having said all that if you look at the current ranchu branch you'll see
the delta has come down a fair bit and is in itself relatively
self-contained. This should reduce the pain of regularly re-basing and
I'm sure Google don't want to go through the major upheaval moving from
the very old QEMU fork that the current emulator to a more modern QEMU
too often.

I'm hopeful we can get to a point where basic Android support is
up-stremable (and defended upstream) and the heavy android specific
stuff becomes a simple mechanical re-basing operations. Of the android
changes (off the top of my head) we have:

* Machine descriptions (fairly self-contained)
* Simple event driver (again self-contained)
* android_pipe services (self-contained but replicates virt-io functionality)
* android console support (provides ADB specific interfaces to QEMU)
* Simple Android Frame Buffer
* OpenGL (out-of-tree, likely very android specific)

I suspect the first 2 or 3 could be up-streamed without too much trouble
but it would be interesting to know if having this basic android emulation 
in master would be of any interest to the wider community?


-- 
Alex Bennée