Re: [Xen-devel] [PATCH] xl/libxl: add pvcalls support

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

On Thu, 29 Mar 2018, Ian Jackson wrote:
> Stefano Stabellini writes ("[PATCH] xl/libxl: add pvcalls support"):
> > Add pvcalls support to libxl and xl. Create the appropriate pvcalls
> > entries in xenstore.
> ...
> > +#### ~/device/pvcalls/$DEVID/* []
> > +
> > +Paravirtualized POSIX function calls frontend. Described by
> > +[docs/misc/pvcalls.markdown][PVCALLS]
> 
> It's not entirely clear what the semantics are if multiple pvcalls
> devices are provided.  Which is the guest expected to use ?
> 
> Perhaps the doc should state some convention, if there is one.  I hope
> there is such a convention ($DEVID usually 0 maybe?)

It would be similar to providing two network cards to the guest. Either
one can be used. But there is no way to provide meta-information on
which one should be used for what at the moment. As you point out, and
as per other PV protocols, the first one uses DEVID 0.


> > +    for (i = 0; i < d_config->num_pvcallss; i++)
> 
> The name `pvcallss' is clumsy.  But I'm not sure I have a much better
> suggestion.
> 
> One idea might be to rename your whole thing `pvrpc' since it's a
> general RPC scheme, more or less.  Except that I don't want to come in
> now and say you should rename it.  And also most rpc systems have an
> idl language and you have ad hoc binary structs.

I don't think it is a good idea at this stage. All the documents and
presentations refer to it as "pvcalls" including
docs/misc/pvcalls.markdown.


> Have you considered calling this `pvcallsifs' ?  Where `if' is
> `intrerface' ?  Or something ?

This is a good suggestion, thank you. I'll send a v2 of the patch.


> Anyway, I would like you to think about this and answer my questions
> but I don't think it's a blocker. 

Thank you for the good feedback.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel