Re: [Minios-devel] [PATCH v2 0/15+5+5] Begin to disentangle libxenctrl and provide some stable libraries

[Ian Campbell <ian.campbell@citrix.com>]

(dropping mini-os-devel and some cc's, adding David)

Hi David,

On Wed, 2015-07-15 at 16:46 +0100, Ian Campbell wrote:
> (this is clearly not 4.6 material, aiming for 4.7)
> 
> In <1431963008.4944.80.camel@citrix.com> I proposed stabilising some
> parts of the libxenctrl API/ABI by disaggregating into separate
> libraries.
> 
[...]
> Still to come would be libraries for specific out of tree purposes
> (device model, kexec),

For kexec I have ("S" column is "interface to the left is stable A(BP)I"):

Interface                          S Underlying Interface           S Other users
---------------------------------- - ------------------------------ - ---------------
`xc__hypercall_buffer_array_alloc`   Should use libxencall
`xc_hypercall_buffer_array_create`   Should use libxencall
`xc_hypercall_buffer_array_des...`   Should use libxencall
`xc_interface_close`
`xc_interface_open`
`xc_get_max_cpus`                  N `xc_physinfo=SYSCTL_physinfo`  N many
`xc_version`                       N `XENVER_capabilities`          Y libxl,others
`xc_get_machine_memory_map`        N `XENMEM_machine_memory_map`    Y libxl

`xc_kexec_exec`                    N `KEXEC_CMD_kexec`              Y None
`xc_kexec_get_range`               N `KEXEC_CMD_kexec_get_range`    Y None
`xc_kexec_load`                    N `KEXEC_CMD_kexec_load`         Y None
`xc_kexec_unload`                  N `KEXEC_CMD_kexec_unload`       Y None

It seems to me that there is not all that much utility to providing a
stable libxenkexec containing those last four, and that they might as well
be moved to kexec-tools where they can be implemented using the new
libxencall (which also includes the buffer allocation stuff for the first
3).

What do you think?

That would just leave xc_get_max_cpus, xc_version and
xc_get_machine_memory_map, which I'm still pondering.

Ian.