From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:50948) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RBY1n-00068E-UN for qemu-devel@nongnu.org; Wed, 05 Oct 2011 16:25:22 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RBY1k-0001KC-W0 for qemu-devel@nongnu.org; Wed, 05 Oct 2011 16:25:19 -0400 Received: from mx1.redhat.com ([209.132.183.28]:39601) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RBY1k-0001Io-MH for qemu-devel@nongnu.org; Wed, 05 Oct 2011 16:25:16 -0400 From: Juan Quintela In-Reply-To: <4E8CB7F2.7000405@codemonkey.ws> (Anthony Liguori's message of "Wed, 05 Oct 2011 15:02:58 -0500") References: <4E8B182D.9050603@codemonkey.ws> <4E8CB7F2.7000405@codemonkey.ws> Date: Wed, 05 Oct 2011 22:25:06 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [Qemu-devel] [PATCH 17/23] migration: make sure we always have a migration state Reply-To: quintela@redhat.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: qemu-devel@nongnu.org Anthony Liguori wrote: > On 10/04/2011 09:49 AM, Juan Quintela wrote: >> Anthony Liguori wrote: >>> On 09/23/2011 07:57 AM, Juan Quintela wrote: [ much more stuff ] >> It avoids s==NULL checks, > > In favor of s->state == MIG_STATE_NONE. > >> and it also avoids having to have new >> variables (max_throotle) just because we don't have a migration state >> handy. > > The intention of the global variable is to set a default for new > sessions. I can imagine a world where if you had parallel migrations, > you could either toggle the default (the global variable) or the > specific parameter within a single migration session. > > But it's not about features. It's a general reluctances to heavily > modify the code to rely on a global instead of passing the state > around. Here's a pretty good short write up of why this is a Bad > Thing. > > http://stackoverflow.com/questions/1392315/problems-with-singleton-pattern > > Ultimately, MIG_STATE_NONE shouldn't be needed because we should not > be relying on a singleton accessor to get the MigrationState. A > better cleanup would be to further pass MigrationState between > functions and eliminate the need for a global at all. I understand the singleton problem, but the reason to put STATE_NONE is not for that O:-) (it just happens that we only have a migration now). Why I want it? Just now, the only thing that we are "setting" for a migration before it starts is the "bandwidth". I see the future when migration becomes something like: migration_set_speed .... migration_set_target .... migration_set_ migrate as you can see, we are "preparing" migration, and we don't have a "STATE" now that describes this state, migration not started, but we want to prepare it. Perhaps a better name that STATE_NONE is in order. I got NONE in the sense that "migration" has not been attemted yet. Later, Juan.