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 <pbonz...@redhat.com> >>>> 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