[Xen-devel] REST MAINTAINERS feedback requested Was:Re: [PATCH v5 01/28] HYPERCALL_version_op. New hypercall mirroring XENVER_ but sane.

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 31.03.16 at 15:28, <konrad.wilk@xxxxxxxxxx> wrote:
> On Thu, Mar 31, 2016 at 06:07:58AM -0600, Jan Beulich wrote:
>> >>> On 31.03.16 at 13:43, <konrad@xxxxxxxxxx> wrote:
>> > it should not really be there but in a new hypercall that can do
>> > three arguments (the length) and be able to return -EPERM. A sane
>> > one, not the cobbled up XENVER one.
>> 
>> Well, -EPERM is now possible with the old one too. And nothing
>> in that existing interface prevents a length to be passed in/out
>> for new sub-ops. Nor do I really see anything truly insane with
> 
> We cannot expand the hypercall to have three arguments - it MUST
> have two (as you had pointed out earlier). The length must be jammed
> in the sub-ops:

Right, that's what I had implied.

Jan

> /* Return value is the number of bytes written, or XEN_Exx on error.
>  * Calling with empty parameter returns the size of build_id. */
> 
> #define XENVER_build_id 10
> struct xen_build_id {
>         uint32_t        len; /* IN: size of buf[]. */
> #if defined(__STDC_VERSION__) && __STDC_VERSION__ >= 199901L
>         unsigned char   buf[];
> #elif defined(__GNUC__)
>         unsigned char   buf[1]; /* OUT: Variable length buffer with 
> build_id. */
> #endif
> };
> typedef struct xen_build_id xen_build_id_t;
> 
>> that existing interface.
>> 
>> Jan
>> 




_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel