From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MePrU-00053k-6N for qemu-devel@nongnu.org; Fri, 21 Aug 2009 04:52:40 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MePrO-00050g-Em for qemu-devel@nongnu.org; Fri, 21 Aug 2009 04:52:38 -0400 Received: from [199.232.76.173] (port=56724 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MePrO-00050S-54 for qemu-devel@nongnu.org; Fri, 21 Aug 2009 04:52:34 -0400 Received: from mx1.redhat.com ([209.132.183.28]:52245) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MePrN-0002BS-Jc for qemu-devel@nongnu.org; Fri, 21 Aug 2009 04:52:33 -0400 Received: from int-mx07.intmail.prod.int.phx2.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.20]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id n7L8qWgM028385 for ; Fri, 21 Aug 2009 04:52:32 -0400 Message-ID: <4A8E6049.6020609@redhat.com> Date: Fri, 21 Aug 2009 10:52:25 +0200 From: Gerd Hoffmann MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH 21/23] Port PCIDevice state to VMState References: <20ca5615c8cdc456296698133e3b0dbd5a1f4de7.1250788880.git.quintela@redhat.com> In-Reply-To: <20ca5615c8cdc456296698133e3b0dbd5a1f4de7.1250788880.git.quintela@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Juan Quintela Cc: qemu-devel@nongnu.org On 08/20/09 19:42, Juan Quintela wrote: > This uses a variant of buffer, with extra checks. Also uses the new > support for cheking that a read value is less or equal than a field. Hmm, why you are hopping through all these loops? I'd just keep the existing pci_device_{save,load} functions. load anyway for backward compatibility. save also for devices not yet converted to vmstate. I think alot of the complex stuff you are building up here isn't needed then, unless I missed something ... Beside that we'll have to think about how to handle versioning of structs. Do we want vmstate_pci_device (and all others) have its own version? Probably makes sense. Handling this should go into the generic code then and not be hacked into each structure using VMSTATE_INT32_LE(). cheers, Gerd