>>> On 11.04.16 at 18:25, <ian.jack...@eu.citrix.com> 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 16:22, <ian.jack...@eu.citrix.com> wrote:
>> > 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.
>
> I agree that duplication is bad, all other things being equal.
>
> 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.
> I don't see an explicit deprecation in the patch that is in tree, but
> it seems to me to be intended (and, perhaps, implied). Certainly if
> we are going to permit these strings etc. to be bigger than fits in
> the old hypercall, the old hypercall needs to be deprecated on the
> grounds that it can provide incomplete or inaccurate information.
>
> Does this way of looking at it help ?
If that means you approve of the introduction of the new hypercall,
yes. After all the goal of this whole discussion is to determine
whether another maintainer is willing to provide a replacement ack
for the withdrawn one.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
