From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:59018) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XegAt-0006ub-MI for qemu-devel@nongnu.org; Thu, 16 Oct 2014 04:12:49 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XegAn-0006zm-Ah for qemu-devel@nongnu.org; Thu, 16 Oct 2014 04:12:43 -0400 Received: from mx1.redhat.com ([209.132.183.28]:65316) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XegAn-0006zQ-3q for qemu-devel@nongnu.org; Thu, 16 Oct 2014 04:12:37 -0400 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s9G8Ca2c021590 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Thu, 16 Oct 2014 04:12:36 -0400 Date: Thu, 16 Oct 2014 09:12:32 +0100 From: "Dr. David Alan Gilbert" Message-ID: <20141016081232.GF2590@work-vm> References: <1413446034-25167-1-git-send-email-dgilbert@redhat.com> <1413446034-25167-2-git-send-email-dgilbert@redhat.com> <8738aofnd6.fsf@elfo.elfo> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8738aofnd6.fsf@elfo.elfo> Subject: Re: [Qemu-devel] [PATCH 1/3] Start moving migration code into a migration directory List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Juan Quintela Cc: qemu-devel@nongnu.org, ehabkost@redhat.com * Juan Quintela (quintela@redhat.com) wrote: > "Dr. David Alan Gilbert (git)" wrote: > G> From: "Dr. David Alan Gilbert" > > > > The migration code now occupies a fair chunk of the top level .c > > files, it seems time to give it it's own directory. > > > > I've not touched: > > arch_init.c - that's mostly RAM migration but has a few random other > > bits > > Will split the memory bits, and can go to migration. > > > savevm.c - because it's built target specific > > Damn, would have to look at it. Yes; I suspect it's the vmstate_register_ram that uses TARGET_PAGE_MASK, one of the patches in my postcopy world adds a function in exec.c that returns TARGET_PAGE_BITS so that stuff that needs to know target page size can make a call to find it out; that might solve that. Dave > > > block-migration.c - should that go in block/ or migration/ ? > > It is really on migration. we have basically: > > - ram-migration > - block-migration > > We can call other names if people preffer. > > > > > This is purely a code move; no code has changed. > > > > Signed-off-by: Dr. David Alan Gilbert > > Thanks, Juan. > -- Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK