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?

On Mon, Oct 03, 2005 at 05:58:44PM -0500, Anthony Liguori 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 :-)

Yes, it's just as gross as varargs.

> The kernel interface doesn't generalize well--we could hack it to have 
> an additional domid_t * parameter but that kind of sucks.

That would indeed suck and we're not considering such a specific interface.

> I was thinking of just adding a param to the message that specified the 
> number of entries in the array.  That solves that problem.

I personally don't like the array, it's awkward to allocate, and we'll
still use strlen(path)+1 to fill it in since that's how data goes
across the bus...

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

So we'd pass &array[1] and the number of entries to the watch callbacks?

    christian


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

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