Re: Stabilising some tools only HVMOPs?

["Jan Beulich" <JBeulich@suse.com>]

>>> On 18.02.16 at 11:45, <wei.liu2@citrix.com> wrote:
> On Thu, Feb 18, 2016 at 03:37:06AM -0700, Jan Beulich wrote:
>> >>> On 18.02.16 at 11:24, <ian.campbell@citrix.com> wrote:
>> > On Wed, 2016-02-17 at 17:28 +0000, Wei Liu wrote:
>> >> The list of tools only HVMOPs used by QEMU are:
>> >> 
>> >>   #define HVMOP_track_dirty_vram    6
>> >>   #define HVMOP_modified_memory    7
>> >>   #define HVMOP_set_mem_type    8
>> >>   #define HVMOP_inject_msi         16
>> >>   #define HVMOP_create_ioreq_server 17
>> >>   #define HVMOP_get_ioreq_server_info 18
>> >>   #define HVMOP_map_io_range_to_ioreq_server 19
>> >>   #define HVMOP_unmap_io_range_from_ioreq_server 20
>> >>   #define HVMOP_destroy_ioreq_server 21
>> >>   #define HVMOP_set_ioreq_server_state 22
>> >> 
>> >> I'm curious about the rationale for making them tools only in the
>> >> first place and what needs to be done to make them stable.
>> > 
>> > FWIW (IMHO, YMMV etc) it is becoming increasing incorrect to consider the
>> > device model as "tools" in the face of disaggregation and support for
>> > (nearly) arbitrary upstream QEMU versions etc.
>> 
>> As just written in the other reply, it depends on what exactly
>> qemu uses: libxc interfaces are fine, since the "tools only"
>> aspect in the public headers is mainly to allow us to alter
>> structure layouts and alike. The "tools only" aspect there in
>> particular is not to preclude entities like qemu (indirectly)
>> invoking such operations - that's instead being dealt with by
>> permission checks.
>> 
>> I.e. as long a qemu doesn't define __XEN_TOOLS__ for its
>> building, I think we're fine.
>> 
> 
> OK, so you're suggesting building stable APIs on top of unstable ones.

No, sorry, I'm not, after having read your and Ian's earlier replies.

Jan