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

[Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>]

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 08.04.16 at 19:41, <andrew.cooper3@xxxxxxxxxx> wrote:
> > 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.

I'm trying to understand what your alternative suggestion is.  Could
you please be more explicit ?

I'm reading xen/include/public/version.h.  (Sadly it doesn't have the
API doc markup.)  AFAICT there is a XENVER_xxxx sub-op namespace which
permits extensions to the XENVER hypercall.

But does that permit the caller to specify their buffer size ?

> > 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.

Ie I think ^ this is for me a key question.

> 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.

I don't think I would be content with simply adding a new sub-op with
bigger fixed-length fields.

Ian.

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