From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Mntpf-0004MW-6L for qemu-devel@nongnu.org; Wed, 16 Sep 2009 08:41:59 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MntpZ-0004KP-H3 for qemu-devel@nongnu.org; Wed, 16 Sep 2009 08:41:58 -0400 Received: from [199.232.76.173] (port=47761 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MntpY-0004KI-SE for qemu-devel@nongnu.org; Wed, 16 Sep 2009 08:41:53 -0400 Received: from mx20.gnu.org ([199.232.41.8]:43742) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MntpY-0002Dk-Ef for qemu-devel@nongnu.org; Wed, 16 Sep 2009 08:41:52 -0400 Received: from mx1.redhat.com ([209.132.183.28]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MntpX-000451-Jy for qemu-devel@nongnu.org; Wed, 16 Sep 2009 08:41:51 -0400 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id n8GCfoMA011774 for ; Wed, 16 Sep 2009 08:41:50 -0400 Date: Wed, 16 Sep 2009 15:40:03 +0300 From: "Michael S. Tsirkin" Message-ID: <20090916124002.GC4729@redhat.com> References: <20090916104620.GA4456@redhat.com> <20090916111845.GJ23157@redhat.com> <20090916115726.GL23157@redhat.com> <20090916123535.GM23157@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090916123535.GM23157@redhat.com> Subject: [Qemu-devel] Re: optional feature List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gleb Natapov Cc: qemu-devel@nongnu.org, Juan Quintela On Wed, Sep 16, 2009 at 03:35:35PM +0300, Gleb Natapov wrote: > So? I don't get your point. We are talking about how we can add features > to devices and don't break migration, no? One way is to have "migration containers" > for each isolated feature (I don't like to call them "imaginary devices"). Yay, containers is a good term, especially in virtualization context :)