Re: [PATCH v2 5/5] libxl: Add explicit cast to libxl_psr_cat_set_cbm

From: Ian Campbell <ian.campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Chester Lin <czylin@uwaterloo.ca>
Cc: stefano.stabellini@eu.citrix.com, george.dunlap@eu.citrix.com,
	dario.faggioli@citrix.com, xen-devel@lists.xen.org,
	jtotto@uwaterloo.ca, hjarmstr@uwaterloo.ca
Subject: Re: [PATCH v2 5/5] libxl: Add explicit cast to libxl_psr_cat_set_cbm
Date: Tue, 19 Jan 2016 14:21:27 +0000	[thread overview]
Message-ID: <1453213287.29930.52.camel@citrix.com> (raw)
In-Reply-To: <22174.17133.666899.340909@mariner.uk.xensource.com>

On Tue, 2016-01-19 at 14:06 +0000, Ian Jackson wrote:
> I am not a fan of the cast as a solution.  I would rather, prefer to
> regularise the situation.  If my co-maintainers agree about the
> desirability of expecting libxl callers to use enum values from Xen
> public headers,

libxl_shutdown_reason has the same issues, libxl_tsc_mode also might, as
might libxl_timer_mode. I'm not sure if there are others. I think we
generally handle all these the way psr is handled today (with casts and/or
explicit conversion switches).

I think part of the problem is that it is hard to expose just the desired
bits through to the user of libxl without also exposing the full xen
hypercall interface (the vast majority of which would be inappropriate to
expose to them since libxl is suppose to encapsulate such things).

If we can find a way to allow this without that downside and while
preserving API compat that would be ok.

>  then I would want to:
> 
>  * Change the hypervisor interface
>  * Abolish the libxc and libxl enums
>  * Provide a compatibility layer in libxl for users of the old
>    enum value names and the old type names (do we need to keep
>    the old enum in the IDL or does our API stability guarantee apply
>    to the generated C bindings?)

I think we do need to keep the compat, yes, the fact that bit of the C API
is autogenerated makes no difference to the end user. The compat API is
only needed for callers who define LIBXL_API_VERSION to some older version
though (I think, do check the libxl.h comments in case I'm misremembering
what we say).

As a possible alternative, we could make it such that the IDL generator
knows about the linkage and enforces the use of the same values, and
automatically provides conversion helpers (essential a cast wrapped in some
syntax) for _internal_ use.

Ian.

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