[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


On 09/04/2019 12:42, 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".

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.

Actually, it will not be fine at least for the read case. The return value is a 32-bit value (on AArch32 and if you want to keep compat between 64-bit and 32-bit). A negative value indicates an error. As we return the number of characters read, it means we can only handle 2GB.

So I would rather limit the buffer to 2GB for everyone.


Julien Grall

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.