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 18:25, <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 16:22, <Ian.Jackson@xxxxxxxxxxxxx> 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@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel