Re: xm list d flag?

[Christian Limpach <Christian.Limpach@cl.cam.ac.uk>]

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