Roger Pau Monné writes ("Re: [PATCH v2 02/21] libxl: introduce a way to mark
fields as deprecated in the idl"):
> Thanks for the review. I've fixed all the other comments on the series
> and started an osstest flight, my aim is to post a new version of the
> series using the same deprecation idl
On Wed, Sep 20, 2017 at 04:46:16PM +0100, Ian Jackson wrote:
> Roger Pau Monne writes ("[PATCH v2 02/21] libxl: introduce a way to mark
> fields as deprecated in the idl"):
> > The deprecation involves generating a function that copies the
> > deprecated fields into it's new location if the new
Wei Liu writes ("Re: [PATCH v2 02/21] libxl: introduce a way to mark fields as
deprecated in the idl"):
> On Wed, Sep 20, 2017 at 04:46:16PM +0100, Ian Jackson wrote:
...
> > We discussed how this might be done better. To me it seems like the
> > only really plausible alternative was to replace
On Wed, Sep 20, 2017 at 04:46:16PM +0100, Ian Jackson wrote:
> Roger Pau Monne writes ("[PATCH v2 02/21] libxl: introduce a way to mark
> fields as deprecated in the idl"):
> > The deprecation involves generating a function that copies the
> > deprecated fields into it's new location if the new
Roger Pau Monne writes ("[PATCH v2 02/21] libxl: introduce a way to mark fields
as deprecated in the idl"):
> The deprecation involves generating a function that copies the
> deprecated fields into it's new location if the new location has not
> been set.
Hi. We had an IRL conversation which I
The deprecation involves generating a function that copies the
deprecated fields into it's new location if the new location has not
been set.
The fields that are going to be shared between PVH and HVM or between
PVH and PV are moved to the top level of libxl_domain_build_info, and
the old
