From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Liguori Subject: Re: xm list d flag? Date: Sat, 01 Oct 2005 20:47:16 -0500 Message-ID: <433F3C24.5020104@us.ibm.com> References: <1128169060.3668.177.camel@pluto.linsolutions.com> <20051001144045.GA12651@uk.xensource.com> <433EE75F.9090606@us.ibm.com> <20051001204616.GJ10661@cl.cam.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20051001204616.GJ10661@cl.cam.ac.uk> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Christian Limpach Cc: Rusty Russell , xen-devel@lists.xensource.com, Ewan Mellor List-Id: xen-devel@lists.xenproject.org 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. > > > >