Re: [Xen-devel] [PATCH 3/4] xen/public: Document HYPERCALL_console_io()

[Julien Grall <julien.grall@xxxxxxx>]

Hi Jan,

On 4/9/19 12:42 PM, Jan Beulich wrote:
> > > > On 09.04.19 at 13:26, <julien.grall@xxxxxxx> wrote:
> > On 03/04/2019 14:04, Jan Beulich wrote:
> > > Also please note the quotation used by the mentioned
> > > existing doc comments, as well as a few other formal aspects
> > > (like them also making clear what the return type is). I think
> > > that's a model used elsewhere as well, so I think you should
> > > follow it here.
> > I haven't replicated the ` because I have no idea what they are used for. I
> > would appreciate if you provide pointer how to use them.
> Well, I can only point you at the history of things, e.g.
> 262e118a37 "docs/html/: Annotations for two hypercalls".
Thank you for the pointer. However, we don't seem to use this formatting 
everywhere. For instance, the formatting used in my patch seems to be 
consistent with xen/include/public/vcpu.h.
Furthermore, the description of the hypercall is done on top of the 
definition of the hypercall number. Before I rework this patch, could we 
agree on what formatting we want?
> > > The other thing is: As mentioned elsewhere, I don't think the
> > > first two parameters should be plain int. I'm not happy to see
> > > this proliferate into documentation as well, i.e. I'd prefer if
> > > this was corrected before adding documentation. Would you
> > > be willing to do this, or should I add it to my todo list?
> > While switching from cmd from signed to unsigned should be ok. This would
> > introduce a different behavior of for count.
> Since this removes an error condition, I think this is an okay change
> to happen, without ...
>
> > Are we happy with that, or shall we add a check ((int)count) > 0?
> ... any such extra check. This also isn't going to introduce any new
> real risk of a long running operation or some such - if 2Gb of input
> data are fine, I can't see why 4Gb wouldn't be, too.
Fair point. I will update the prototype accordingly.

Cheers,

--
Julien Grall

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