From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1MijZN-00043D-Tx
	for qemu-devel@nongnu.org; Wed, 02 Sep 2009 02:43:50 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1MijZJ-0003zN-CG
	for qemu-devel@nongnu.org; Wed, 02 Sep 2009 02:43:49 -0400
Received: from [199.232.76.173] (port=60593 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1MijZJ-0003zF-35
	for qemu-devel@nongnu.org; Wed, 02 Sep 2009 02:43:45 -0400
Received: from mx1.redhat.com ([209.132.183.28]:36546)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <kraxel@redhat.com>) id 1MijZG-0003td-V8
	for qemu-devel@nongnu.org; Wed, 02 Sep 2009 02:43:44 -0400
Message-ID: <4A9E141A.7000605@redhat.com>
Date: Wed, 02 Sep 2009 08:43:38 +0200
From: Gerd Hoffmann <kraxel@redhat.com>
MIME-Version: 1.0
Subject: Re: [Qemu-devel] [PATCH 1/4] qdev: integrate reset
References: <1251791775-5358-1-git-send-email-kraxel@redhat.com>
	<1251791775-5358-2-git-send-email-kraxel@redhat.com>
	<f43fc5580909010930s56affafdi880667809e097fcf@mail.gmail.com>
In-Reply-To: <f43fc5580909010930s56affafdi880667809e097fcf@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Blue Swirl <blauwirbel@gmail.com>
Cc: qemu-devel@nongnu.org

On 09/01/09 18:30, Blue Swirl wrote:
> On Tue, Sep 1, 2009 at 10:56 AM, Gerd Hoffmann<kraxel@redhat.com>  wrote:
>
>> @@ -110,6 +110,9 @@ struct DeviceInfo {
>>      Property *props;
>>      int no_user;
>>
>> +    /* callbacks */
>> +    QEMUResetHandler *reset;
>> +
>
> This would remove the need for registration but I had in my mind a bit
> more complex solution like VMState structures. Even better, VMState
> could be enhanced so that the reset value of the fields could be
> specified (when not zero).

Interesting idea.  Could work out pretty nicely.  Chances are that the 
overlap of the fields which must be initialized on reset and which must 
be saved on migration is pretty high.  If so the integration into 
vmstate would indeed make alot of sense.

cheers,
   Gerd