Re: [Xen-devel] [RFC PATCH 6/6] xc_version: add vm_event interface version

[Tamas K Lengyel <tamas.k.lengyel@xxxxxxxxx>]

On Tue, Feb 12, 2019 at 11:20 AM Razvan Cojocaru
<rcojocaru@xxxxxxxxxxxxxxx> wrote:
>
> On 2/12/19 8:13 PM, Tamas K Lengyel wrote:
> > On Tue, Jan 8, 2019 at 9:39 AM Razvan Cojocaru
> > <rcojocaru@xxxxxxxxxxxxxxx> wrote:
> >>
> >> On 1/8/19 6:27 PM, Jan Beulich wrote:
> >>>>>> On 19.12.18 at 19:52, <ppircalabu@xxxxxxxxxxxxxxx> wrote:
> >>>> Signed-off-by: Petre Pircalabu <ppircalabu@xxxxxxxxxxxxxxx>
> >>>
> >>> An empty description is not helpful. The immediate question is: Why?
> >>> We don't do this for other interface versions. I'm unconvinced a
> >>> special purpose piece of information like this one belongs into the
> >>> rather generic version hypercall.
> >>
> >> For an introspection application meant to be deployed on several Xen
> >> versions without recompiling, it is important to be able to decide at
> >> runtime what size and layout the vm_event struct has.
> >>
> >> Currently this can somewhat be done by associating the current version
> >> with the vm_event version, but that is not ideal for obvious reasons.
> >
> > We do exactly that in LibVMI and it works fine - care to elaborate
> > what problem you have with doing that? There is a 1:1 match between
> > any stable Xen version and a vm_event interface version. I don't think
> > we will ever have a situation where we bump the vm_event interface
> > version but not the Xen release version.
>
> XenServer. Any given version of XenServer may or may not fit the matrix
> you're talking about (because some patches are backported, some are not,
> etc.). In which case it all becomes very complicated.

Ah yes, if custom patches are applied on top I can see how that could
become a problem.

Thanks,
Tamas

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel