From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([140.186.70.92]:39535)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <kraxel@redhat.com>) id 1RW8qW-0000jE-W0
	for qemu-devel@nongnu.org; Thu, 01 Dec 2011 10:46:49 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <kraxel@redhat.com>) id 1RW8qS-0003eJ-Eg
	for qemu-devel@nongnu.org; Thu, 01 Dec 2011 10:46:48 -0500
Received: from mx1.redhat.com ([209.132.183.28]:14501)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <kraxel@redhat.com>) id 1RW8qS-0003e0-6A
	for qemu-devel@nongnu.org; Thu, 01 Dec 2011 10:46:44 -0500
Message-ID: <4ED7A159.20902@redhat.com>
Date: Thu, 01 Dec 2011 16:46:33 +0100
From: Gerd Hoffmann <kraxel@redhat.com>
MIME-Version: 1.0
References: <1322687028-29714-1-git-send-email-aliguori@us.ibm.com>
	<1322687028-29714-15-git-send-email-aliguori@us.ibm.com>
In-Reply-To: <1322687028-29714-15-git-send-email-aliguori@us.ibm.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] [PATCH 14/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: Anthony Liguori <aliguori@us.ibm.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, Markus Armbruster <armbru@redhat.com>, Luiz Capitulino <lcapitulino@redhat.com>

  Hi,

> +static void rtc_get_date(DeviceState *dev, Visitor *v, void *opaque,
> +                         const char *name, Error **errp)
> +{
> +    ISADevice *isa = DO_UPCAST(ISADevice, qdev, dev);
> +    RTCState *s = DO_UPCAST(RTCState, dev, isa);
> +
> +    visit_start_struct(v, NULL, "struct tm", name, 0, errp);
> +    visit_type_int32(v, &s->current_tm.tm_year, "tm_year", errp);
> +    visit_type_int32(v, &s->current_tm.tm_mon, "tm_mon", errp);
> +    visit_type_int32(v, &s->current_tm.tm_mday, "tm_mday", errp);
> +    visit_type_int32(v, &s->current_tm.tm_hour, "tm_hour", errp);
> +    visit_type_int32(v, &s->current_tm.tm_min, "tm_min", errp);
> +    visit_type_int32(v, &s->current_tm.tm_sec, "tm_sec", errp);
> +    visit_end_struct(v, errp);
> +}

Ok, what is the long term plan here?  I don't think we want open-code
everything here, do we?  Especially once visitors become more widespread
used.  And I can see that they are useful for a bunch of stuff beside
device properties and relationships.  vmstate for example.  Or to list
device state (say a register dump) for debugging purposes.

Today we have code to generate structs and visitors from scratch.
I think it would be useful to also generate visitors for existing
structs, with some kind of annotation, like this ...

struct SomeDev {
      DeviceState dev;
      Chardev     *chr;
      uint32_t    reg1   __v(vmstate);
      uint32_t    reg2   __v(vmstate);
      [ ... ]
);

... instead of the vmstate structs we create manually today.  Likewise
for properties.  And probably we can even generate different visitors
for different "views" at the same struct.

cheers,
  Gerd