From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([140.186.70.92]:51794)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <kraxel@redhat.com>) id 1RaOyc-00078i-6Q
	for qemu-devel@nongnu.org; Tue, 13 Dec 2011 04:48:50 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <kraxel@redhat.com>) id 1RaOyW-0006km-KH
	for qemu-devel@nongnu.org; Tue, 13 Dec 2011 04:48:46 -0500
Received: from mx1.redhat.com ([209.132.183.28]:1776)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <kraxel@redhat.com>) id 1RaOyW-0006kN-4y
	for qemu-devel@nongnu.org; Tue, 13 Dec 2011 04:48:40 -0500
Message-ID: <4EE71F6F.4000208@redhat.com>
Date: Tue, 13 Dec 2011 10:48:31 +0100
From: Gerd Hoffmann <kraxel@redhat.com>
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>
In-Reply-To: <4EE71A69.4070508@redhat.com>
Content-Type: text/plain; charset=ISO-8859-1
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: Kevin Wolf <kwolf@redhat.com>
Cc: 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>

  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);
};

cheers,
  Gerd