[Qemu-devel] Merge qemu android

[Qemu-devel] Merge qemu android

[Bastien ROUCARIES]

Hi,

What is the step in order to get qemu android merged mainline ?

http://android.git.kernel.org/?p=platform/external/qemu.git;a=summary

Regards

Bastien

[Qemu-devel] Re: Merge qemu android

[Bastien ROUCARIES]

On Thu, Jan 21, 2010 at 5:27 PM, Bastien ROUCARIES
<roucaries.bastien@gmail.com> wrote:
> Hi,
>
> What is the step in order to get qemu android merged mainline ?
>
> http://android.git.kernel.org/?p=platform/external/qemu.git;a=summary
>
> Regards
>
> Bastien
>

BTW i am volonteer for the merge

Diff is 20M and I ask how can I splip it...

Bastien

Re: [Qemu-devel] Merge qemu android

[Anthony Liguori]

On 01/21/2010 10:27 AM, Bastien ROUCARIES wrote:
> Hi,
>
> What is the step in order to get qemu android merged mainline ?
>
> http://android.git.kernel.org/?p=platform/external/qemu.git;a=summary
>    

Send patches.

It's very difficult to merge downstream code unless that entire 
downstream is committed to working through upstream.  I'd suggest 
encouraging the Android developers to commit to pushing all of the 
functionality upstream before going down this path.

Regards,

Anthony Liguori

> Regards
>
> Bastien
>
>
>    

Fwd: [Qemu-devel] Merge qemu android

[Bastien ROUCARIES]

[-- Attachment #1: Type: text/plain, Size: 923 bytes --]

Forget to cc

On Sat, Jan 23, 2010 at 11:40 PM, Anthony Liguori <anthony@codemonkey.ws>wrote:

> On 01/21/2010 10:27 AM, Bastien ROUCARIES wrote:
>
>> Hi,
>>
>> What is the step in order to get qemu android merged mainline ?
>>
>> http://android.git.kernel.org/?p=platform/external/qemu.git;a=summary
>>
>>
>
> Send patches.
>
> It's very difficult to merge downstream code unless that entire downstream
> is committed to working through upstream.  I'd suggest encouraging the
> Android developers to commit to pushing all of the functionality upstream
> before going down this path.
>

I know but the code base is really different they use 0.8.2 as a base, and i
was thinking of porting to upstream.
They use also craps like sdl :S

I think a total rewritte will be better .

How can incremently add a new arch to qemu or a new plateform ?

Bastien

Regards,
>
> Anthony Liguori
>
>  Regards
>>
>> Bastien
>>
>>
>>
>>
>
>

[-- Attachment #2: Type: text/html, Size: 1976 bytes --]

Re: [Qemu-devel] Merge qemu android

[Laurent Desnogues]

On Thu, Jan 28, 2010 at 11:44 AM, Bastien ROUCARIES
<roucaries.bastien@gmail.com> wrote:
> Forget to cc
>
> On Sat, Jan 23, 2010 at 11:40 PM, Anthony Liguori <anthony@codemonkey.ws>
> wrote:
>>
>> On 01/21/2010 10:27 AM, Bastien ROUCARIES wrote:
>>>
>>> Hi,
>>>
>>> What is the step in order to get qemu android merged mainline ?
>>>
>>> http://android.git.kernel.org/?p=platform/external/qemu.git;a=summary
[...]
>
> I know but the code base is really different they use 0.8.2 as a base, and i
> was thinking of porting to upstream.

Really?  The tree you point to above has TCG.  Or is it unused?

> They use also craps like sdl :S

Mainline QEMU does too.


Laurent

Re: [Qemu-devel] Merge qemu android

[David Turner]

[-- Attachment #1: Type: text/plain, Size: 1174 bytes --]

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



> Bastien
>
> Regards,
>>
>> Anthony Liguori
>>
>>  Regards
>>>
>>> Bastien
>>>
>>>
>>>
>>>
>>
>>
>
>

[-- Attachment #2: Type: text/html, Size: 2721 bytes --]

[Qemu-devel] Re: Merge qemu android

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 1841 bytes --]

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_<xxxx>.c in the Android codebase, corresponding
> to the emulated hardware
> - hw/android_arm.c to be ported to upstream too

Pushing that bits upstream, converting them to qdev etc. should be a
good plan for whoever wants to make a start - even at the risk of
"forking" from Google's code base. I guess at some point you will be
allowed to adjust your strategy and join that effort simply because
maintaining your own tree became too expensive.

> - a few changes to the slirp code to setup the default network redirections

That sounds strange given that slirp is fairly configurable during
runtime these days. Can you elaborate?

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

I think upstream would already benefit from having support for booting
images, being able to stimulate most inputs, enabling users to play with
virtual phones and allowing developers to debug (upstream) kernels.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 257 bytes --]

Re: [Qemu-devel] Merge qemu android

[Anthony Liguori]

[-- Attachment #1: Type: text/plain, Size: 1802 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 3278 bytes --]

Re: [Qemu-devel] Merge qemu android

[Bastien ROUCARIES]

[-- Attachment #1: Type: text/plain, Size: 1362 bytes --]

On Fri, Jan 29, 2010 at 3:41 AM, David Turner <digit@google.com> 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_<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.
>

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

[-- Attachment #2: Type: text/html, Size: 3480 bytes --]

Re: [Qemu-devel] Merge qemu android

[David Turner]

[-- Attachment #1: Type: text/plain, Size: 1388 bytes --]

Anthony is right, and unfortunately the Android team doesn't have the
bandwidth to support sending patches to upstream
at the moment.

Note that our version of QEMU is a rather complex mix of 0.8.2 and upstream.
I routinely cherry pick upstream improvements
and incorporate them to the codebase. However, I'm also pretty conservative
and try to avoid stuff we don't depend on and
which risk breaking other stuff easily so many parts don't get in, or are
implemented differently.

Also, many, many things in the Android emulator codebase have very little
value for upstream qemu, imho.

Bastien, what specific features are you interested in ? I can still have a
look at what would be required to generate the
corresponding upstream patch.

On Sat, Jan 23, 2010 at 2:40 PM, Anthony Liguori <anthony@codemonkey.ws>wrote:

> On 01/21/2010 10:27 AM, Bastien ROUCARIES wrote:
>
>> Hi,
>>
>> What is the step in order to get qemu android merged mainline ?
>>
>> http://android.git.kernel.org/?p=platform/external/qemu.git;a=summary
>>
>>
>
> Send patches.
>
> It's very difficult to merge downstream code unless that entire downstream
> is committed to working through upstream.  I'd suggest encouraging the
> Android developers to commit to pushing all of the functionality upstream
> before going down this path.
>
> Regards,
>
> Anthony Liguori
>
>  Regards
>>
>> Bastien
>>
>>
>>
>>
>
>
>
>

[-- Attachment #2: Type: text/html, Size: 2201 bytes --]

Re: [Qemu-devel] Merge qemu android

[Luiz Capitulino]

On Thu, 28 Jan 2010 18:35:16 -0800
David Turner <digit@google.com> wrote:

> Anthony is right, and unfortunately the Android team doesn't have the
> bandwidth to support sending patches to upstream
> at the moment.

 You should also consider the benefits for yourself of merging your bits
upstream: more peer review, more testing, potential improvements and
maybe better integration.

> Note that our version of QEMU is a rather complex mix of 0.8.2 and upstream.
> I routinely cherry pick upstream improvements
> and incorporate them to the codebase. However, I'm also pretty conservative
> and try to avoid stuff we don't depend on and
> which risk breaking other stuff easily so many parts don't get in, or are
> implemented differently.

 Do you ever consider rebasing someday?

> Also, many, many things in the Android emulator codebase have very little
> value for upstream qemu, imho.
> 
> Bastien, what specific features are you interested in ? I can still have a
> look at what would be required to generate the
> corresponding upstream patch.
> 
> On Sat, Jan 23, 2010 at 2:40 PM, Anthony Liguori <anthony@codemonkey.ws>wrote:
> 
> > On 01/21/2010 10:27 AM, Bastien ROUCARIES wrote:
> >
> >> Hi,
> >>
> >> What is the step in order to get qemu android merged mainline ?
> >>
> >> http://android.git.kernel.org/?p=platform/external/qemu.git;a=summary
> >>
> >>
> >
> > Send patches.
> >
> > It's very difficult to merge downstream code unless that entire downstream
> > is committed to working through upstream.  I'd suggest encouraging the
> > Android developers to commit to pushing all of the functionality upstream
> > before going down this path.
> >
> > Regards,
> >
> > Anthony Liguori
> >
> >  Regards
> >>
> >> Bastien
> >>
> >>
> >>
> >>
> >
> >
> >
> >