[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH v3 00/14] qemu: generate acpi tables for the gue
From: |
Andreas Färber |
Subject: |
Re: [Qemu-devel] [PATCH v3 00/14] qemu: generate acpi tables for the guest |
Date: |
Fri, 26 Jul 2013 14:25:42 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 |
Am 25.07.2013 19:18, schrieb Michael S. Tsirkin:
> On Thu, Jul 25, 2013 at 05:50:55PM +0200, Andreas Färber wrote:
>> Am 24.07.2013 18:01, schrieb Michael S. Tsirkin:
>>> This code can also be found here:
>>> git://git.kernel.org/pub/scm/virt/kvm/mst/qemu.git acpi
>>>
>>> Please review, and consider for 1.6.
>>
>> Quite frankly, this is still not looking the way I imagined it based on
>> the KVM call discussion and Anthony's comments that I remember:
>
> By the way, for examples which are exactly
> like this code here, look no further than:
>
> FWCfgState *fw_cfg_find(void);
>
> and the use in hw/misc/pvpanic.c of said API.
>
> Here we have device implementing an API to find it, and through this
> pointer, it is accessed by more APIs access its state.
>
> This is exactly what my patches do for piix etc.
>
> So if you don't like this approach, please change
> existing code using it.
According to git-blame that code was recently added by you:
http://repo.or.cz/w/qemu.git/commit/600c60b76d0682f6c39d19bfff79da9321e8cf86?f=hw/nvram/fw_cfg.c
So the existing-code argument is kind of moot. ;)
Further, that returns the device's state struct and does not copy fields
from that state struct into another state struct.
BTW if you want to avoid repeatedly hardcoding things, fw_cfg should be
using object_resolve_path_component(), I'll prepare a patch.
Andreas
--
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg