From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Msxwd-0000NN-NI for qemu-devel@nongnu.org; Wed, 30 Sep 2009 08:06:07 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MsxwY-0000Jf-Oa for qemu-devel@nongnu.org; Wed, 30 Sep 2009 08:06:07 -0400 Received: from [199.232.76.173] (port=34541 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MsxwY-0000JU-FF for qemu-devel@nongnu.org; Wed, 30 Sep 2009 08:06:02 -0400 Received: from mx1.redhat.com ([209.132.183.28]:15528) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MsxwX-0003pV-SG for qemu-devel@nongnu.org; Wed, 30 Sep 2009 08:06:02 -0400 From: Juan Quintela In-Reply-To: (malc's message of "Wed, 30 Sep 2009 15:47:17 +0400 (MSD)") References: Date: Wed, 30 Sep 2009 14:05:32 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [Qemu-devel] Re: [PATCH 27/49] ac97: add active to the state List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: malc Cc: qemu-devel@nongnu.org malc wrote: > On Wed, 30 Sep 2009, Juan Quintela wrote: > active doesn't belong in the above structure, it's not used for anything > other than save/loadvm. It is used for reset, for instance. We can discuss if it belongs there or not, but will let that for another day. > If this "design" doesn't allow this, either find > another way to accomplish the same or fix the "design". VMStateDescription is a list of offsets from a known address. Address is the one from the state. That is the design. Now, back to ac97. Rest of ac97 don't need the active field, because it is stored anywhere else (basically where AUD_set_active* store it). Clearly it is part of ac97 state, becase it is needed for load/save/reset to work properly. It just happens that it is stored anywhere else for the design of the audio system. At load/save time we don't want to call malloc(), and now we have descriptions of the state, not functions that save/load the state. Only sane way of storing this kind of variables is storing them into the state. Sorry, there is no way that we are going to have a declarative description of the state and retain the old functions to do save/load. You can only get only declarative description or functions, not both. There are more temporary variables in other devices, and this was the way it was done there. Normally I would have called it active_vmstate to make that explicit, but here, it was also used for reset, that is the way I named it with the _vmstate suffix. Later, Juan.