Re: REST MAINTAINERS feedback requested Was:Re: [PATCH v5 01/28] HYPERCALL_version_op. New hypercall mirroring XENVER_ but sane.

["Jan Beulich" <JBeulich@suse.com>]

>>> On 11.04.16 at 19:13, <Ian.Jackson@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 18:25, <Ian.Jackson@eu.citrix.com> 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.

We cannot, ever, remove a not toolstack limited hypercall completely
(or if, then only by Kconfig option so that people knowing none of the
guests they care about use such deprecated ones).

>> > 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.
> 
> Err.  Well, I am still asking questions.  When I said "does that help"
> I was meaning something like "does that help bring you closer to
> agreement with Andrew".  But I don't want to focus on procedure here.

Oh, well, in that case the answer is "no". Bike shed issue or not,
having to maintain two pieces of code with similar functionality is
undesirable. And it's not like we didn't have any XSA for that
(apparently trivial) piece of code already.

Jan


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