Christopher Covington <c...@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
