From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:36764) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RdNQ8-0006xS-23 for qemu-devel@nongnu.org; Wed, 21 Dec 2011 09:45:32 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RdNQ2-0001tA-Fc for qemu-devel@nongnu.org; Wed, 21 Dec 2011 09:45:28 -0500 Received: from mail-iy0-f173.google.com ([209.85.210.173]:58450) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RdNQ2-0001t2-7b for qemu-devel@nongnu.org; Wed, 21 Dec 2011 09:45:22 -0500 Received: by iagj37 with SMTP id j37so13572994iag.4 for ; Wed, 21 Dec 2011 06:45:21 -0800 (PST) Message-ID: <4EF1F0FE.4060402@codemonkey.ws> Date: Wed, 21 Dec 2011 08:45:18 -0600 From: Anthony Liguori MIME-Version: 1.0 References: <1319735193-4718-1-git-send-email-mdroth@linux.vnet.ibm.com> <1319735193-4718-2-git-send-email-mdroth@linux.vnet.ibm.com> <4EF06D87.9000809@redhat.com> <4EF092A5.3070108@codemonkey.ws> <4EF09C14.9070102@redhat.com> <4EF0F689.7090806@codemonkey.ws> <4EF1D291.8010203@redhat.com> In-Reply-To: <4EF1D291.8010203@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v2 01/10] qapi: add Visitor interfaces for uint*_t and int*_t List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: qemu-devel , Michael Roth , Juan Quintela On 12/21/2011 06:35 AM, Paolo Bonzini wrote: > On 12/20/2011 09:56 PM, Anthony Liguori wrote: >>> As always, you can implement that in many ways. However, I think the >>> point of using Visitors is not to remove QEMUFile. >> >> Yes, it is. > > The point of using Visitors is to provide a standard representation of device > state. QEMUFile is but one consumer of that representation, along with any other > migration filter. Can you do a quick code mock up of how you'd expect this to work? I'm not sure if I'm just being dense, but I'm having a really hard time understanding what you're suggesting. How I see this evolving with Mike's series is: struct DeviceStateClass { ObjectClass parent; void (*load_state)(DeviceState *obj, Visitor *v, const char *name, Error **errp); void (*save_state)(DeviceState *obj, Visitor *v, const char *name, Error **errp); }; The PCIDevice base class would expose: /* protected */ void pci_load_state(PCIDevice *obj, Visitor *v, const char *name, Error **errp) { visit_start_struct(v, "PCIDevice", name, errp); visit_type_int8(v, &obj->reg[0], "reg[0]", errp); .. visit_end_struct(v, errp); } Or: static VMStateDescription pci_device_desc = { .name = "PCIDevice", .fields = { VMSTATE_UINT8(PCIDevice, reg[0]), ... } }; void pci_load_state(PCIDevice *obj, Visitor *v, const char *name, Error **errp) { visit_with_vmstate(v, obj, &pci_device_desc, name, errp); } A subclass would do: static void my_device_load_state(DeviceState *obj, Visitor *v, const char *name, Error **errp) { MyDevice *s = MY_DEVICE(obj); visit_start_struct(v, "MyDevice", name, errp); pci_load_state(PCI_DEVICE(obj), v, "super", errp); visit_end_struct(v, errp); } static void my_device_class_init(ObjectClass *klass, void *data) { DeviceClass *dc = DEVICE_CLASS(klass); dc->load_state = my_device_load_state; ... } There's no reference at all to QEMUFile. The load_state/save_state methods can be exposed as a "state" property too. Once the series 2/4 lands and Mike's series, implementing this should be very straight forward. Regards, Anthony Liguori