Re: xm list d flag?

[Anthony Liguori <aliguori@us.ibm.com>]

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.
>
>
>  
>