[Top][All Lists]

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

Re: [Qemu-devel] [PATCH 0/4] More core code ENV_GET_CPU removals

From: Paolo Bonzini
Subject: Re: [Qemu-devel] [PATCH 0/4] More core code ENV_GET_CPU removals
Date: Tue, 26 May 2015 10:25:40 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0

On 26/05/2015 10:20, Andreas Färber wrote:
> Am 26.05.2015 um 10:05 schrieb Paolo Bonzini:
>> On 26/05/2015 08:10, Andreas Färber wrote:
>>> Am 25.05.2015 um 15:08 schrieb Paolo Bonzini:
>>>> On 25/05/2015 08:22, Peter Crosthwaite wrote:
>>>>> Hi Andreas, Richard and all,
>>>>> I'm moving towards the goal of having no core code usages of ENV_GET_CPU.
>>>>> This has two advantages:
>>>>> 1: It means we are closer to common-obj'ing core code like exec.c, cpus.c
>>>>> and friends.
>>>>> 2: Multi arch is easier if ENV_GET_CPU stays arch specific. It means I
>>>>> don't need those patches where I reorder the env within the arch specific
>>>>> CPUState. This allows continuing placement of arch specifics before the
>>>>> env in the CPU container (which has TCG perf advantages).
>>>>> There's a couple more after this pack to get the multi-arch thing going,
>>>>> but due to point 1, I'm sending this ahead as I think it has standalone 
>>>>> value.
>>>>> Regards,
>>>>> Peter
>>>>> Peter Crosthwaite (4):
>>>>>   translate-all: Change tb_flush env argument to cpu
>>>>>   gdbserver: _fork: Change fn to accept cpu instead of env
>>>>>   cpus: Change tcg_cpu_exec arg to cpu, not env
>>>>>   cpus: Change exec_init arg to cpu, not env
>>> [...]
>>>> Thanks, queued for 2.4.
>>> Apparently after qom-next you also want to take over qom-cpu, once again
>>> without pinging me first.
>> Uhm...
>> Main loop
>> M: Paolo Bonzini <address@hidden>
>> S: Maintained
>> F: cpus.c
>> F: main-loop.c
>> F: qemu-timer.c
>> F: vl.c
>> translate-all.c is "Odd fixes" with no specific maintainer, and
>> gdbserver.c is not in MAINTAINERS altogether.
> ENV_GET_CPU() is my QOM CPU macro.

Please, this is ridiculous.  MAINTAINERS talks about files, not about
macros.  If somebody misuses the memory API and I'm on vacation (I know
you're not, this is an example), I fix it myself, I don't complain with
whomever applied the patches.

> You picked the patchset up just hours
> after it arrived on the list, on a holiday, without giving me a chance
> to review. It's not about which tree it goes through, it's about you not
> asking first - which I reminded you of just days ago, so this appears
> deliberate.

It certainly is.


reply via email to

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