From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([140.186.70.92]:39262)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <anthony@codemonkey.ws>) id 1RaSTr-0002Cs-9t
	for qemu-devel@nongnu.org; Tue, 13 Dec 2011 08:33:19 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <anthony@codemonkey.ws>) id 1RaSTi-0007oc-60
	for qemu-devel@nongnu.org; Tue, 13 Dec 2011 08:33:15 -0500
Received: from mail-yw0-f45.google.com ([209.85.213.45]:47990)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <anthony@codemonkey.ws>) id 1RaSTi-0007oS-3c
	for qemu-devel@nongnu.org; Tue, 13 Dec 2011 08:33:06 -0500
Received: by yhgg71 with SMTP id g71so423266yhg.4
	for <qemu-devel@nongnu.org>; Tue, 13 Dec 2011 05:33:05 -0800 (PST)
Message-ID: <4EE7540F.3080703@codemonkey.ws>
Date: Tue, 13 Dec 2011 07:33:03 -0600
From: Anthony Liguori <anthony@codemonkey.ws>
MIME-Version: 1.0
References: <1322857256-14951-1-git-send-email-aliguori@us.ibm.com>	<1322857256-14951-16-git-send-email-aliguori@us.ibm.com>	<4EE1F052.1020703@redhat.com>	<4EE2085F.2060604@us.ibm.com>
	<4EE21579.8090404@redhat.com>	<4EE21A48.1070701@codemonkey.ws>
	<4EE71A69.4070508@redhat.com> <4EE71F6F.4000208@redhat.com>
In-Reply-To: <4EE71F6F.4000208@redhat.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] [PATCH v2 15/18] rtc: add a dynamic property for
 retrieving the date
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Gerd Hoffmann <kraxel@redhat.com>
Cc: Kevin Wolf <kwolf@redhat.com>, Peter Maydell <peter.maydell@linaro.org>, Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>, Jan Kiszka <jan.kiszka@siemens.com>, qemu-devel@nongnu.org, Luiz Capitulino <lcapitulino@redhat.com>, Markus Armbruster <armbru@redhat.com>

On 12/13/2011 03:48 AM, Gerd Hoffmann wrote:
>    Hi,
>
>> Now I understand that for dynamically created properties (like on your
>> PCB) this is necessary and can't be avoided. For about 99% of the
>> devices static definition of properties would be enough, though.
>>
>> So basically what I'm asking for is getting the static structs back for
>> the 99% and have common code that parses them and calls the appropriate
>> functions to actually the properties. The remaining 1% that
>> creates/deletes properties during runtime and isn't covered can directly
>> call whatever it needs.
>
> Fully agree.  I guess we can even generate those structs in many cases.
>   We will parse the ${device}State structs anyway for visitor-based
> vmstate, so with some extra declaration we can generate property
> descriptions too.  For example this ...
>
> static PCIDeviceInfo intel_hda_info = {
>      .qdev.name    = "intel-hda",
>      [ ... ]
>      .qdev.props   = (Property[]) {
>          DEFINE_PROP_UINT32("debug", IntelHDAState, debug, 0),
>          DEFINE_PROP_UINT32("msi", IntelHDAState, msi, 1),
>          DEFINE_PROP_END_OF_LIST(),
>      }
> };
>
> ... could be just ...
>
> struct IntelHDAState {
>      [ ... ]
>      /* properties */
>      uint32_t debug __property(0);
>      uint32_t msi   __property(1);
> };


Yup, that's where I want to go.  In qom-next, I've started splitting header 
files out specifically so we can do stuff like this.  There's quite a bit of 
work to do before we can really start exploring here but I think it's not that 
much work to get the pc device models cleaned up such that we could run qc 
against the headers.

Regards,

Anthony Liguori

>
> cheers,
>    Gerd
>
>