Re: [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 11.04.16 at 16:22, <Ian.Jackson@xxxxxxxxxxxxx> wrote:
> Konrad Rzeszutek Wilk writes ("Re: REST MAINTAINERS feedback requested 
> Was:Re: [Xen-devel] [PATCH v5 01/28] HYPERCALL_version_op. New hypercall 
> mirroring XENVER_ but sane."):
>> On Mon, Apr 11, 2016 at 11:50:25AM +0100, Ian Jackson wrote:
>> > I don't think I would be content with simply adding a new sub-op with
>> > bigger fixed-length fields.
>> 
>> It was variable-ish.
> ...
>> /* 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[];
> 
> This is pretty ugly but tolerable.
> 
> The comment introducing the new HYPERCALL_version_op mentions some
> other differences with HYPERCALL_xen_version, which seem to suggest
> other deficiencies in the latter.  Those deficiencies, together with
> the ugliness of the above, would tend to suggest to me that a cleaner
> new interface is warranted.
> 
> But to an extent some of this conversation seems to be on matters of
> taste.

Agreed.

> Jan, what is the downside of introducing a new hypercall ?

Duplicate code effectively doing the same thing.

Jan


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