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 19:13, <Ian.Jackson@xxxxxxxxxxxxx> wrote:
> Jan Beulich writes ("Re: REST MAINTAINERS feedback requested Was:Re: 
> [Xen-devel] [PATCH v5 01/28] HYPERCALL_version_op. New hypercall mirroring 
> XENVER_ but sane."):
>> On 11.04.16 at 18:25, <Ian.Jackson@xxxxxxxxxxxxx> wrote:
>> > But any improvement from an old API to a new one necessarily involves
>> > providing a dual facility during a transition period.
>> 
>> Except that, at least for most sub-ops, the new one doesn't really
>> provide much advantage, and hence dealing with the lack of size
>> for those sub-ops where it matters within the existing hypercall
>> (perhaps by adding one or two new sub-ops) would limit duplication
>> quite a bit.
> 
> ISTM that the lower duplication (which in principle is an advantage
> which will be time limited if we are ever able to completely remove
> teh old hypercall) comes with the cost of (in the long term) increased
> mess in this particular subop.
> 
> Is that right ?  Obviously this cost is not very significant.  But
> maybe the duplication isn't that significant either.  I was kind of
> expecting to find stronger arguments on both sides in this
> discussion...

If, btw, the cost of having to read the length argument from guest
memory was deemed undesirable, we'd certainly have the option
of specifying it to be passed through, say, the high half of the
current "cmd" parameter.

Jan


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