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] xm list d flag?

To: Christian Limpach <Christian.Limpach@xxxxxxxxxxxx>
Subject: Re: [Xen-devel] xm list d flag?
From: Anthony Liguori <aliguori@xxxxxxxxxx>
Date: Sat, 01 Oct 2005 20:47:16 -0500
Cc: Rusty Russell <rusty@xxxxxxxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx, Ewan Mellor <ewan@xxxxxxxxxxxxx>
Delivery-date: Sun, 02 Oct 2005 01:44:55 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <20051001204616.GJ10661@xxxxxxxxxxxx>
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: <1128169060.3668.177.camel@xxxxxxxxxxxxxxxxxxxxxx> <20051001144045.GA12651@xxxxxxxxxxxxxxxx> <433EE75F.9090606@xxxxxxxxxx> <20051001204616.GJ10661@xxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mozilla Thunderbird 1.0.6 (X11/20050912)
Christian Limpach wrote:

On Sat, Oct 01, 2005 at 02:45:35PM -0500, Anthony Liguori wrote:
One thing to consider is having the drivers destroy the backend devices on a @releaseDomain watch instead of on the front-end path disappearing.

Yes, I think this would make sense.  We still need to keep the current
behaviour as well, it is needed for hot-unplug of devices.

I'd like to see @releaseDomain also pass along the domain id, so
that we don't need to scan all domains in several places.

This would be equally useful for @introduceDomain too. It should simplify the code in a number of places (at least in Xend and consoled).

To do this,
we should switch the order of the arguments in the watch vectors,
allowing us then to pass an arbitrary number of arguments without
having to change the interface to support an arbitrary number of
arguments[1].  An additional use for this for regular watches could
be to pass all the elements of the path which triggered the watch to
fire as seperate arguments, reducing the amount of code in the drivers
which does string parsing.
Is changing the order of token and path really necessary? It's a considerably simplier change if we maintain the same order. I've always thought of the token as an argument so this order makes more sense to me (and I reckon to Rusty since he did it this way to begin with :-)).

The only adjustment to the userspace API would be that instead of returning an char *[2] we would return a char *[] that was terminated by a NULL. xenbus needs a little more but it's not too bad.

Regards,

Anthony Liguori

   christian

[1] additional arguments are at vec[1] + strlen(vec[1]) + 1 and so on,
the callback will need to know how many arguments get passed.




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

<Prev in Thread] Current Thread [Next in Thread>