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

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


  • To: Julien Grall <julien.grall@xxxxxxx>
  • From: Jan Beulich <JBeulich@xxxxxxxx>
  • Date: Mon, 5 Aug 2019 10:07:34 +0000
  • Accept-language: en-US
  • Arc-authentication-results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=suse.com;dmarc=pass action=none header.from=suse.com;dkim=pass header.d=suse.com;arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=2iAl66YqPaPW8VsRCTaE5mJsuKjdKsgiiFHWBa6yEfk=; b=ZkTQel5YGI78reYyNGfMbAO+HslFgqqx472TKsMUXOeFtJHaWlL6ZEnfndmikGDhxDFNLS3faIUll71vAhX7PGcs0Y+sMH0Lhwjb831WSnFLCibww2uY0dj6q7pIGeRa/ajtp8X9R8LiqViCeu6gTsRN6LmuuH3HYsYuueb28mLv6b8K/X7NusqlpcRaahH4mjQd9EPqgY01XReoswWlCgE8/NYDCUNkYL6SFQ0RvC9hTlNDae0s7t0KZ4f5fj1HJYZy9P9sPyVnz2mO/CrDrkI1WXVSJEDfWXrerboolZetvO/CV4NaZjk+76ijdYS9OtOZJLA500n599RokyPerQ==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=BPm2WHD91noE5fsarvrrjq8brMOnqEyQqNf7j4HNTVuVwN7M765S4pAUg0PqxI0xbO4efFR68DydBILpb1Ov9UfdX1YaDR1cAu9qI7VmvB+DFEJ6A7+/2f6kuFgEmKVtgYZUsPCi7C2qnsxJrCVCp1infwzt7MjoTy0a+vTlVRKAI+FSH4/OpW8UsQJcZIK9jaWQS5eWI2NqdeQHVA8lR3BgJds767YimkqyOUUIhJWQJzQtzwY55nUK4DHl1+gKPZeg8+vJYsqYHeYCwf8kkBBuKkFAccIzp8awmZb3XKjwFQGCgkSx7R7ZlMVAv/StJ1/g2pGXAFPxKT9pWPE+mg==
  • Authentication-results: spf=none (sender IP is ) smtp.mailfrom=JBeulich@xxxxxxxx;
  • Cc: Stefano Stabellini <sstabellini@xxxxxxxxxx>, Wei Liu <wei.liu2@xxxxxxxxxx>, Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>, George Dunlap <George.Dunlap@xxxxxxxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>, Tim Deegan <tim@xxxxxxx>, xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Mon, 05 Aug 2019 10:08:50 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
  • Thread-index: AQHVS3HlX+Sguj+jtEyHOttiG5U4NqbsVE8A
  • Thread-topic: [PATCH 3/4] xen/public: Document HYPERCALL_console_io()

On 05.08.2019 11:40, Julien Grall wrote:
> Hi,
> 
> 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.

Hmm, valid point.

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

Probably fair enough then (if explicitly stated). Personally I would
nevertheless allow sizes up to 4Gb-4kb, but I can see why this may
not be liked by everyone. I'd like to point out though that the
PTR_ERR() machinery we've inherited from Linux utilizes exactly that.

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

 


Rackspace

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