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 08.04.16 at 19:41, <andrew.cooper3@xxxxxxxxxx> wrote:
> On 08/04/16 18:21, Ian Jackson 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 Fri, Apr 08, 2016 at 10:33:33AM -0600, Jan Beulich wrote:
>>>> Yet nothing has happened, so I think the patch needs to be
>>>> reverted (at least for the time being).
>>> Wait what?!
>> I'm sorry that I didn't understand that we were being asked for a
>> second opinion about this disagreement.  I'm afriad that the original
>> email wasn't really comprehensible to me as a summary of the
>> disagreement.
>>
>> Would someone please summarise ?  Especially, since Jan is AFAICT
>> saying that this new hypercall is not needed, it would be helpful to
>> know why those who think it is needed want it.
> 
> The new hypercall is very definitely needed, which is why I requested it
> during earlier revisions of the xsplice series.
> 
> The interface for the old version was sufficiently useless that build_id
> can't be added to it.  (Specifically, there is no ability to return
> varialble length data).

This is simply not true: The hypercall being passed a void handle,
everything can be arranged for without introducing a new
hypercall.

>  Also, by its design, it has some
> unreasonably-short limits on extraversion and changesetinfo, both of
> which could do with being longer for distros trying to encode "delta
> from upstream" information.
> 
> The new hypercall has a ration interface where you don't blindly trust
> that the caller passed you a pointer to a suitably-sized structure.

While the new one is indeed slightly neater, that's not sufficient
for such redundancy imo. That's the whole reason for withdrawing
my ack _without_ making it an explicit NAK.

Jan


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