WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

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

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




_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

<Prev in Thread] Current Thread [Next in Thread>