From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NagnI-0007pu-V5 for qemu-devel@nongnu.org; Thu, 28 Jan 2010 21:41:13 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NagnE-0007me-6w for qemu-devel@nongnu.org; Thu, 28 Jan 2010 21:41:12 -0500 Received: from [199.232.76.173] (port=42585 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NagnD-0007mV-Vl for qemu-devel@nongnu.org; Thu, 28 Jan 2010 21:41:08 -0500 Received: from smtp-out.google.com ([216.239.33.17]:47855) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1NagnD-0007Ss-EZ for qemu-devel@nongnu.org; Thu, 28 Jan 2010 21:41:07 -0500 Received: from kpbe20.cbf.corp.google.com (kpbe20.cbf.corp.google.com [172.25.105.84]) by smtp-out.google.com with ESMTP id o0T2f4W0024827 for ; Fri, 29 Jan 2010 02:41:05 GMT Received: from iwn39 (iwn39.prod.google.com [10.241.68.103]) by kpbe20.cbf.corp.google.com with ESMTP id o0T2f3Q2026361 for ; Thu, 28 Jan 2010 18:41:03 -0800 Received: by iwn39 with SMTP id 39so1433233iwn.1 for ; Thu, 28 Jan 2010 18:41:03 -0800 (PST) MIME-Version: 1.0 In-Reply-To: <195c7a901001280244n13f3afeen45a7c65922b9f0b7@mail.gmail.com> References: <195c7a901001210827i29b91f30p3a80c2a8a0c2b4bb@mail.gmail.com> <4B5B7AFB.9040506@codemonkey.ws> <195c7a901001280244i36d09907gb1e9ea387c526255@mail.gmail.com> <195c7a901001280244n13f3afeen45a7c65922b9f0b7@mail.gmail.com> Date: Thu, 28 Jan 2010 18:41:02 -0800 Message-ID: <60cad3f1001281841m24cd0cd0t485cf97b1da60585@mail.gmail.com> Subject: Re: [Qemu-devel] Merge qemu android From: David Turner Content-Type: multipart/alternative; boundary=001636c5971b0c1c12047e4491cd List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Bastien ROUCARIES Cc: qemu-devel@nongnu.org --001636c5971b0c1c12047e4491cd Content-Type: text/plain; charset=ISO-8859-1 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. 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 >>> >>> >>> >>> >> >> > > --001636c5971b0c1c12047e4491cd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Jan 28, 2010 at 2:44 AM, Bastien ROUCARI= ES <rou= caries.bastien@gmail.com> wrote:
They use also cr= aps like sdl :S


T= hat's totally orthogonal to upstream QEMU. The code for our SDL-support= ed 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 in= cremently 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:

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

that should be it, though I cannot guarantee success at this point. Also y= ou 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




--001636c5971b0c1c12047e4491cd--