[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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.


Anthony Liguori


[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



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.