Re: [Qemu-devel] [PATCH] finally kill cpudef config section support

[Andreas Färber]

Am 09.12.2012 21:46, schrieb Blue Swirl:
> On Sun, Dec 9, 2012 at 7:13 PM, Andreas Färber <address@hidden> 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