From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1OB1Hf-0000cE-Dm for qemu-devel@nongnu.org; Sun, 09 May 2010 03:50:43 -0400 Received: from [140.186.70.92] (port=52225 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OB1Hd-0000bI-SP for qemu-devel@nongnu.org; Sun, 09 May 2010 03:50:42 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OB1Hc-00086f-KM for qemu-devel@nongnu.org; Sun, 09 May 2010 03:50:41 -0400 Received: from mx1.redhat.com ([209.132.183.28]:31221) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OB1Hc-00086M-Ci for qemu-devel@nongnu.org; Sun, 09 May 2010 03:50:40 -0400 From: Juan Quintela In-Reply-To: <4BE4968B.6050805@web.de> (Jan Kiszka's message of "Sat, 08 May 2010 00:39:07 +0200") References: <4BE4968B.6050805@web.de> Date: Sun, 09 May 2010 09:50:32 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [Qemu-devel] Re: vmstate: Useless post_save? List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jan Kiszka Cc: qemu-devel Jan Kiszka wrote: > Hi all, > > I wondered why we have the post_save callback in vmstate. Conceptually, > it made no sense to me. So I grep'ed for its users - and found exactly > one: tmp105. As suspected, only "strange" code was found: > > static void tmp105_post_save(void *opaque) > { > TMP105State *s = opaque; > s->faults = tmp105_faultq[(s->config >> 3) & 3]; /* F */ > } > > First, s->config cannot be changed by saving the state. And, second, > s->faults is only written by this driver, never read. > > Anyone any concerns dropping 'faults' from tmp105 and then dropping the > post_save handler from vmstate? About 'faults' dropping, I have to opinion at all. It is done this way because old code did it this way. About post_save() it should be there only to "undo" things done in "pre_save" to be able to continue in the source after a failed migration. As you have found, not much users around. If you remove tmp105 user, I vote to remove it. We can "revert" the removal if need appears again. Later, Juan.