From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NauMI-0000Os-9G for qemu-devel@nongnu.org; Fri, 29 Jan 2010 12:10:14 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NauMD-0000Mr-L0 for qemu-devel@nongnu.org; Fri, 29 Jan 2010 12:10:13 -0500 Received: from [199.232.76.173] (port=58175 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NauMD-0000Ml-Hi for qemu-devel@nongnu.org; Fri, 29 Jan 2010 12:10:09 -0500 Received: from mx20.gnu.org ([199.232.41.8]:36759) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1NauLk-0007PZ-6d for qemu-devel@nongnu.org; Fri, 29 Jan 2010 12:10:09 -0500 Received: from mail-ew0-f227.google.com ([209.85.219.227]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NauKn-0001YC-3p for qemu-devel@nongnu.org; Fri, 29 Jan 2010 12:08:41 -0500 Received: by ewy27 with SMTP id 27so1139346ewy.16 for ; Fri, 29 Jan 2010 09:08:38 -0800 (PST) MIME-Version: 1.0 In-Reply-To: <60cad3f1001281841m24cd0cd0t485cf97b1da60585@mail.gmail.com> References: <195c7a901001210827i29b91f30p3a80c2a8a0c2b4bb@mail.gmail.com> <4B5B7AFB.9040506@codemonkey.ws> <195c7a901001280244i36d09907gb1e9ea387c526255@mail.gmail.com> <195c7a901001280244n13f3afeen45a7c65922b9f0b7@mail.gmail.com> <60cad3f1001281841m24cd0cd0t485cf97b1da60585@mail.gmail.com> Date: Fri, 29 Jan 2010 18:08:30 +0100 Message-ID: <195c7a901001290908n780bbabbhd56d98bf2329472@mail.gmail.com> Subject: Re: [Qemu-devel] Merge qemu android From: Bastien ROUCARIES Content-Type: multipart/alternative; boundary=0015174478985023e2047e50afe7 List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: David Turner Cc: qemu-devel@nongnu.org --0015174478985023e2047e50afe7 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Jan 29, 2010 at 3:41 AM, 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_.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. > It is exactly that I asked. Thank you :) > 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. > > > >> Bastien >> >> Regards, >>> >>> Anthony Liguori >>> >>> Regards >>>> >>>> Bastien >>>> >>>> >>>> >>>> >>> >>> >> >> > --0015174478985023e2047e50afe7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, Jan 29, 2010 at 3:41 AM, David Turner <digit@google.com> wrote:
On Thu, Jan 28, 2010 at 2:44 A= M, Bastien ROUCARIES <roucaries.bastien@gmail.com>= wrote:
They use also cr= aps like sdl :S


=
That's totally orthogonal to upstream QEMU. The code for our SDL-s= upported interface is totally separate from the rest
of QEMU changes (or so I hope), and also different from mainline's sdl.= c
=A0
I think a total rewritte will be better .
=A0
How can incremently add a new arch to qemu or a new plateform ?

Depends on what your goal is. If all you w= ant is to be able to run Android system images in an upstream qemu executab= le,
you will need essentially the following:

- th= e content of hw/goldfish_<xxxx>.c in the Android codebase, correspond= ing to the emulated hardware
- hw/android_arm.c to be ported to u= pstream too
- a few changes to the slirp code to setup the default network redirec= tions
- a few changes to vl.c for setup.
=

It is exactly that I asked.

Thank you :)

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

=A0
Bastien

Regards,

Anthony Liguori

Regards

Bastien


=A0





--0015174478985023e2047e50afe7--