WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] [PATCH 6/9] Linux support for vdevice bus

To: "Rusty Russell" <rusty@xxxxxxxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH 6/9] Linux support for vdevice bus
From: "Jacob Gorm Hansen" <jacobg@xxxxxxx>
Date: Wed, 7 Jun 2006 12:03:15 +0200
Cc: Xen Mailing List <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Wed, 07 Jun 2006 03:03:37 -0700
Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=Gm4l4p6UmHn86xqC3Jwoi4z3EV1I+wbwy8HYEihfa+vtgjr8xeALo+raNcWfQOlsFD7CIu6JJHmT6321zTeuBZuyF4dM6JgynKNkVKdxkh01f43CNyHiIN+8nj9B26PDn7mmlvkujodRswbDTFI5x49nhuRtk+399KbgqpkRJKE=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <1149573287.5183.41.camel@xxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <1149572143.5183.25.camel@xxxxxxxxxxxxxxxxxxxxx> <1149573287.5183.41.camel@xxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
On 6/6/06, Rusty Russell <rusty@xxxxxxxxxxxxxxx> wrote:
Subject: Linux support for vdevice bus

This patch provides the Linux implementation of the vdevice bus.

FIXME: currently it does not support save/restore of the domain: it
should call stop before shutting down, and remap shares afterwards
before calling reconnect.  This depends on exactly what we do with
shared pages on restore.

In general I find the 'remember to suspend on save' approach that we
are currently using for xenbus and drivers problematic, and I much
favor a 'reset on resume' approach instead. Sometimes when doing a
save (or migration, or, in my case, self-migration), the domain wants
to continue running after the save, and then having to shut down all
external devices just to immediately resume them is inelegant and
often creates a lot of trouble. If we are to change the IPC/sharing
mechanism (and you make some good arguments for that), I think we
should design for 'reset on resume' rather than 'suspend-on-save'.

Just my DKK0.02.

Jacob

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel