[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 |