From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1Nat8A-0002hN-32
	for qemu-devel@nongnu.org; Fri, 29 Jan 2010 10:51:34 -0500
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1Nat84-0002fx-VI
	for qemu-devel@nongnu.org; Fri, 29 Jan 2010 10:51:33 -0500
Received: from [199.232.76.173] (port=57273 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1Nat84-0002ft-Rq
	for qemu-devel@nongnu.org; Fri, 29 Jan 2010 10:51:28 -0500
Received: from mail-iw0-f174.google.com ([209.85.223.174]:49780)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <anthony@codemonkey.ws>) id 1Nat84-0006Jg-FP
	for qemu-devel@nongnu.org; Fri, 29 Jan 2010 10:51:28 -0500
Received: by iwn4 with SMTP id 4so1210596iwn.18
	for <qemu-devel@nongnu.org>; Fri, 29 Jan 2010 07:51:27 -0800 (PST)
Message-ID: <4B6303FB.2030308@codemonkey.ws>
Date: Fri, 29 Jan 2010 09:51:23 -0600
From: Anthony Liguori <anthony@codemonkey.ws>
MIME-Version: 1.0
Subject: Re: [Qemu-devel] Merge qemu android
References: <195c7a901001210827i29b91f30p3a80c2a8a0c2b4bb@mail.gmail.com>	<4B5B7AFB.9040506@codemonkey.ws>	<195c7a901001280244i36d09907gb1e9ea387c526255@mail.gmail.com>	<195c7a901001280244n13f3afeen45a7c65922b9f0b7@mail.gmail.com>
	<60cad3f1001281841m24cd0cd0t485cf97b1da60585@mail.gmail.com>
In-Reply-To: <60cad3f1001281841m24cd0cd0t485cf97b1da60585@mail.gmail.com>
Content-Type: multipart/alternative;
	boundary="------------070805010406020305020303"
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: David Turner <digit@google.com>
Cc: Bastien ROUCARIES <roucaries.bastien@gmail.com>, qemu-devel@nongnu.org

This is a multi-part message in MIME format.
--------------070805010406020305020303
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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

--------------070805010406020305020303
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html; charset=ISO-8859-1"
 http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Hi David,<br>
<br>
On 01/28/2010 08:41 PM, David Turner wrote:
<blockquote
 cite="mid:60cad3f1001281841m24cd0cd0t485cf97b1da60585@mail.gmail.com"
 type="cite">
  <div class="gmail_quote">On Thu, Jan 28, 2010 at 2:44 AM, Bastien
ROUCARIES <span dir="ltr">&lt;<a moz-do-not-send="true"
 href="mailto:roucaries.bastien@gmail.com">roucaries.bastien@gmail.com</a>&gt;</span>
wrote:<br>
  <blockquote class="gmail_quote"
 style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
    <div class="gmail_quote">
    <div class="gmail_quote">
    <div>They use also craps like sdl :S<br>
    <br>
    </div>
    </div>
    </div>
  </blockquote>
  <div><br>
  </div>
  <div>That's totally orthogonal to upstream QEMU. The code for our
SDL-supported interface is totally separate from the rest<br>
of QEMU changes (or so I hope), and also different from mainline's sdl.c</div>
  <div>&nbsp;</div>
  <blockquote class="gmail_quote"
 style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
    <div class="gmail_quote">
    <div class="gmail_quote">
    <div>I think a total rewritte will be better .<br>
    <br>
    </div>
    </div>
    </div>
  </blockquote>
  <div>&nbsp;</div>
  <blockquote class="gmail_quote"
 style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
    <div class="gmail_quote">
    <div class="gmail_quote">
    <div>How can incremently add a new arch to qemu or a new plateform ?<br>
    <font color="#888888"><font color="#888888"><br>
    </font></font></div>
    </div>
    </div>
  </blockquote>
  <div>Depends on what your goal is. If all you want is to be able to
run Android system images in an upstream qemu executable,</div>
  <div>you will need essentially the following:</div>
  <div><br>
  </div>
  <div>- the content of hw/goldfish_&lt;xxxx&gt;.c in the Android
codebase, corresponding to the emulated hardware</div>
  <div>- hw/android_arm.c to be ported to upstream too</div>
  <div>- a few changes to the slirp code to setup the default network
redirections</div>
  <div>- a few changes to vl.c for setup.</div>
  <div><br>
  </div>
  <div>that should be it, though I cannot guarantee success at this
point. Also you will miss many features of the emulator, but<br>
as I already said, this should not be a concern for upstream
maintainers at all.</div>
  </div>
</blockquote>
<br>
It would certainly be helpful if you could give us a more detailed list
of the features of the Android emulator.&nbsp; 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.<br>
<br>
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).&nbsp; I
don't think that belongs in QEMU and I think we've discussed this
before.&nbsp; But beyond that, I'm curious what you currently support that
we don't in upstream.<br>
<br>
Regards,<br>
<br>
Anthony Liguori<br>
</body>
</html>

--------------070805010406020305020303--