qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v4 00/36] VMState port of all cpus


From: Juan Quintela
Subject: Re: [Qemu-devel] [PATCH v4 00/36] VMState port of all cpus
Date: Wed, 21 Mar 2012 18:24:46 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.93 (gnu/linux)

Andreas Färber <address@hidden> wrote:
> Am 19.03.2012 23:57, schrieb Juan Quintela:
>> This repository contains all the changes:
>> 
>>   git://repo.or.cz/qemu/quintela.git vmstate-cpus-v4
>> 
>> [v4]
>> - rebase to top
>> - adapt to vmstate.h change
>> - adapt to CPUState -> CPU$archState rename
>> - integrate arm changes in the meantime
>> - add QEMU contributors to the copyright notice of ppc & sparc

[...]
>
> Actually I don't see any CCs at all in this series. Which makes me think
> this is v1 rubbish in the new cover letter. :/

see the changelog for v4. All patches were already reviewed, only
changes were: copyright stuff that Blaw didn't liked (and he was cc'd),
and rebasing (move of  stuff from hw/hw.h to vmstate.h and
s/CPUState/CPU$archState/).

Idea here was not to resend to everybody that already reviewed the
patches another copy.

>
> --cc-cmd="scripts/get_maintainer.pl --nogit-fallback" should work.

nice trick.

> A general comment:
> With regards to the ongoing CPU QOM'ification, if we ever arrive in a
> scenario where we can have multiple targets in one machine, I guess the
> VMState .name "cpu" would cause problems? In that case it might be
> better to use the proposed QOM type names, i.e. "arm-cpu", etc. from the
> start.

At least for x86 we need to maintain backward compatibility.  For the
cest of architectures, we can change it after this series.  It is more,
it would be better to have:  "sparc32-cpu" and "sparc64-cpu", so we
could be able to read the vmstate section without more external info.

I would preffer to do this changes after this series goes in.

[note to all, I am sending a v5 with the changes suggested yesterday by
peter on float32/64 handling ]

Thanks, Juan.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]