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
