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

[Alexander Graf]

On 26.05.15 10:31, Andreas Färber wrote:
> Am 26.05.2015 um 10:25 schrieb Paolo Bonzini:
>>
>>
>> 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.
> 
> Then you can fix up Daniel's patch yourself and I am stepping down as
> maintainer. Have fun.

Please take a big breath and don't do the Jocelyn Mayer thing ;).

How about we have the KVM call today and calmly talk about maintainer
responsibility borders?


Alex