On 07/17/13 17:07, Laszlo Ersek wrote:
> On 07/10/13 15:51, Michael S. Tsirkin wrote:
>> This fills in guest info table with misc
>> information of interest to the guest.
>> Will be used by ACPI table generation code.
>>
>> Signed-off-by: Michael S. Tsirkin <m...@redhat.com>
>> ---
>> hw/acpi/ich9.c | 7 ++++++-
>> hw/acpi/piix4.c | 44 +++++++++++++++++++++++++++++++++++++++++++-
>> hw/i386/Makefile.objs | 2 ++
>> hw/i386/pc.c | 41 +++++++++++++++++++++++++++++++++++++++--
>> hw/i386/pc_piix.c | 15 ++++++++++++---
>> hw/i386/pc_q35.c | 10 +++++++---
>> hw/isa/lpc_ich9.c | 11 +++++++++--
>> hw/mips/mips_malta.c | 2 +-
>> hw/misc/pvpanic.c | 12 +++++++-----
>> hw/pci-host/q35.c | 1 +
>> include/hw/acpi/ich9.h | 2 +-
>> include/hw/i386/ich9.h | 3 ++-
>> include/hw/i386/pc.h | 37 ++++++++++++++++++++++++++++++++++---
>> 13 files changed, 164 insertions(+), 23 deletions(-)
>
> So we won't be fishing in a global pool of information at ACPI table
> creation time as I had expected / advertized before. Instead any
> required bits are gradually collected into the guest info structure
> while creating / configuring the machine.
>
> This is likely a better approach; the set of dependencies for all ACPI
> tables together are tracked explicitly in guest info. Also, we don't
> collect the bits from the outside, breaching encapsulation of devices;
> devices publish the bits.
>
> Reviewed-by: Laszlo Ersek <ler...@redhat.com>
If I understand correctly, based on the recent comments you got from
Gerd and Andreas for this series (in the other, non-repost thread),
fishing in the global pool it should be after all, just with a different
fishing rod than what I used in my original patch ("hw/i386: build ACPI
MADT (APIC) for fw_cfg clients").
These U-turns in design have proved that I'm not qualified to review
this work. So I won't; there's no use in my repeated saying "yeah why
not" to both approaches (which are polar opposites). My apologies.
I applaud your perseverance in this matter.
Laszlo
