Re: [Xen-devel] xm list d flag?

[Anthony Liguori <aliguori@xxxxxxxxxx>]

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