From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Mlml3-0001cC-7g for qemu-devel@nongnu.org; Thu, 10 Sep 2009 12:44:29 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Mlmky-0001Yq-Gq for qemu-devel@nongnu.org; Thu, 10 Sep 2009 12:44:28 -0400 Received: from [199.232.76.173] (port=37692 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Mlmky-0001Yk-B3 for qemu-devel@nongnu.org; Thu, 10 Sep 2009 12:44:24 -0400 Received: from mx1.redhat.com ([209.132.183.28]:1888) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Mlmkx-0007JX-JC for qemu-devel@nongnu.org; Thu, 10 Sep 2009 12:44:23 -0400 From: Juan Quintela In-Reply-To: (malc's message of "Thu, 10 Sep 2009 06:21:50 +0400 (MSD)") References: Date: Thu, 10 Sep 2009 18:44:07 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [Qemu-devel] Re: [PATCH 05/26] Unexport ticks_per_sec variable. Create get_ticks_per_sec() function 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 Thu, 10 Sep 2009, Juan Quintela wrote: > >> malc wrote: >> > On Thu, 10 Sep 2009, Juan Quintela wrote: >> > >> > Point being? >> > >> > [..snip..] >> >> See next patch. We need to put the variable in one struct, we don't >> want to change everything to read the variable from the struct. > > So put the in the _pre vmstate callback (or whatever it's called). > >> >> And at some point code, timer code have to move to qemu-timer.c code, >> not in vl.c. > > So? What is the problem with this approach? ticks_per_sec is not a variable that can _modify_ anybody, it can only be read by anybody. I need to move where it lives now, and probably will be moved again in the near future. What is your problem with exporting a function that gives us exactly what we want? init_timers() <- it initializes it, right to assign to it. save/load vmstate code <- it needs to set it, obviously. Everybody else only uses it as a read only value. What is your problem with giving the value with _one_ function, one value that you can't modify in case that you have one error? I can't see what is your big problem with this patch. I agree that I can achieve the movement to one struct with pre_save/post_load, but I think that this patch is good _independently_ of that. My goal is having less global variables/state not more. And your point to have it as it is today? Later, Juan.