|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [Minios-devel] [PATCH v2 0/15+5+5] Begin to disentangle libxenctrl and provide some stable libraries
(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@xxxxxxxxxx> 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.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |