Am 09.12.2012 21:46, schrieb Blue Swirl: > On Sun, Dec 9, 2012 at 7:13 PM, Andreas Färber <afaer...@suse.de> wrote: >> [...] I would have appreciated a reply >> indicating you agree with Eduardo I should apply it as such or asking >> whether you can apply it now rather than applying this patch without >> anyone's Reviewed-by or Acked-by while my pull is still in flight. > > Actually I checked that it didn't conflict with your pull (which I > applied) and also with your RFC series (which I didn't apply, of > course). So it looked OK to me.
Yes thanks, your merging the ioport pull was indeed appreciated (although it does push the merge conflict to Gerd's earlier ACPI pull). But actually I was referring to my qom-cpu pull. ;) It automatically rebases, too, so no drama. [snip] Thanks for your kind words. I was not trying to push QOM authoring work on you, just wondering about who applies which patches when. What I was looking for is some constructive feedback on what I should or shouldn't do to help clarify responsibilities: > I think it would be nice if you could take patches like this which are > close to your CPU patches and keep them in your tree, or just NAK > patches which conflict with other work. That kind of coordination > would avoid staging problems. I take it that adding an Acked-by to patches and sending a PULL later without sending a "Thanks applied" reply was not a good idea of mine, possibly confusing Anthony's mailbox script. Your response I'm interpreting as I should've replied that I'm investigating the enhancement instead of waiting until I have results to share of whether or not it can be done better in one go (and not as being some formal MAINTAINERS file pattern documentation issue). And my wait on the frozen qom-cpu branch was resolvable with a scripted double-rebase first on qom-cpu, then on master, to simulate a qom-cpu merge for the new follow-up series. > What's for example the plan for Igor's series, should they be applied > next or something else? I've been discussing our next steps with both Igor and Eduardo (who have been frequently rebasing onto each other, leading to some confusion on my part) with no final conclusion. For me it depends how different approaches work out patch-wise. On my x86 radar is this bulk: * finish CPU-as-a-device: the latest series does not realize/init CPUs unlike Anthony's earlier proposal, looks okay otherwise; will affect properties series and is affected by decisions about how to implement QOM realize * VMState: can we reuse DeviceClass::vmsd or do we need our own? open question from Juan's series: how to integrate machine.c VMState code? * subclasses: me having investigated fast-tracking host-x86-cpu; results negative, but starting to be untangled in new series. * sh4/alpha as small test runs for the proposed subclass type name scheme; issue: some targets like sh4 do case-insensitive name comparisons and (unposted) sh4 proposal of CPU name field search does not scale well; to-be-evaluated ideas beyond alpha v2: lower-casing in addition to appending -<arch>-cpu prefix; do we need a CPUClass callback for -cpu argument -> type name or is it a fully-custom per target decision? * avoid and fix the following bug: qemu-system-arm -cpu tmp105 * X86CPU subclasses: me investigating (with interruptions) a slim class_init-based conversion approach without waiting on all properties, to restructure the x86_def_t-centric helper functions * x86 CPU properties: there were still some naming issues in the last version I reviewed, ordering under discussion * HyperV properties: waiting on the previous properties series * QOM realize: if we do realize at device-level and the CPU becomes a device, it will benefit from the infrastructure but will need Object->DeviceState signature changes; realize at device-level cannot propagate recursively through non-device Container (e.g., "/machine", "/machine/unassigned") * lots of open issues: canonical paths for CPUs and their APIC etc. children; more CPU_COMMON->CPUState field moves needed for x86 socket-based hotplug; linux-user cpu_copy() / cpu_clone_regs(); icount field movements causing qtest failure; ... Plus obviously my attempts to bring the remaining non-x86 targets on par. Thanks again for your support in slowly crawling forward there. Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg