From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Liguori Subject: Re: xm list d flag? Date: Mon, 03 Oct 2005 17:58:44 -0500 Message-ID: <4341B7A4.3050808@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> <433F3C24.5020104@us.ibm.com> <20051002032936.GL10661@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: <20051002032936.GL10661@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: >>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 :-)). >> >> > >It's not absolutely necessary, but makes the code simpler sinceat least >within the kernel, we don't pass the token to the watch callback, only >the path and as pointed out in a footnote, you can then get the additional >arguments by adding strlen(path)+1 and so on. > > So you want to just pass around the path pointer? And rely on people jumping past the end of the string? Yikes :-) >>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. >> >> > >Wasn't there a patch which got rid of that array? > I sent a patch that added a size to the array--Rusty didn't like it. Rusty suggested changing the userspace interface to something similiar to the kernel interface. The kernel interface doesn't generalize well--we could hack it to have an additional domid_t * parameter but that kind of sucks. > Also, with a >variable number of paths, using an array will become quite complicated >since you won't know how big to allocate the array. > > I was thinking of just adding a param to the message that specified the number of entries in the array. That solves that problem. >Also, I'd like to see something like XS_WATCH_TOKEN and XS_WATCH_PATH >as indexes into the array instead of sprinking 0/1 althrough the code, >whether we reverse the order or not... > > Yes, I had thought of this myself. I think having xs_read_watch return the size of the array is the best solution. Returning a zero-terminated array makes it difficult to determine if the watch has a feature (if you know the size, you can check for size < XS_WATCH_* to determine if the watch has a given parameter). I'm going to working something up and submit it. Rusty can weigh in when he gets to Cambridge. Regards, Anthony Liguori > christian > > > >