Re: libxl API changes for 4.2 (Was: Re: [PATCH] libxl: do not expose libxenctrl/libxenstore headers via libxl.h)

[Jim Fehlig <jfehlig@novell.com>]

Ian Campbell wrote:
> On Wed, 2011-04-13 at 05:07 +0100, Jim Fehlig wrote:
>   
>> Stefano Stabellini wrote:
>>     
>>> I agree with you on the general principle but I suspect it is going to
>>> be almost a rewrite at the end of this development cycle :-/
>>>   
>>>       
>> :-( For clients' sake, I hope the API stabilizes in 4.2 timeframe,
>>     
>
> We're sorry about this, the API in 4.1 isn't one we are comfortable
> supporting as a long term thing, it has some rough edges and various
> inconsistencies. There's a bit of a chicken and egg situation with the
> clients since sometimes you need to see what users are doing in practice
> in order to figure out what the best long term API is.
>
> We hope to iron it out for the 4.2 release and have a more stable
> interface from then, although of course the API will still evolve, but
> more slowly and the intention is to try and preserve compatibility where
> possible.
>   

Great, thanks.  It would be ideal for a client built against libxl4.2 to
work with libxl4.3 :).

>   
>> and no backports to 4.1 break the API in that branch.
>>     
>
> I think that's something we should be avoiding.
>   

This would be very helpful and much appreciated!

>   
>>   IIRC, there have been
>> other API-incompatible libxl changes since 4.1.
>>     
>
> Yes, there have.
>
> The removal of the domid field from the devices springs to mind (in many
> cases you can omit setting it even on 4.1 though, as it happens). So
> does the change of the ctx type from a struct to an opaque pointer (the
> parent thread of this mail).
>
> Going forward these are the things which spring to mind for 4.2:
>
> Some of the enum value names will also be changed to allow them to be
> more consistently autogenerated (although a compat.h style thing could
> help here).
>
> A related change is the fixing of the TaggedUnion type in the idl into
> something with semantics which map onto language bindings in a sensible
> way.
>
> The specification of specific hvmloader and qemu-dm binaries is also
> likely to be deprecated soon, the user will just need to ask for old or
> new qemu and libxl will figure the rest out (it will still be possible
> to override if desired)
>   

Yep, ability to specify device model binary should be retained.  I don't
know of any users specifying a qemu-dm wrapper via device_model, but
wouldn't be surprised if they exist.

> I've also been wondering what can/should be done about the split between
> libxl_domain_create_info, libxl_domain_build_info and
> libxl_device_model_info now that they are all bundled together in
> libxl_domain_config and not exposed directly in the API (since the
> related functions became internal, that was before 4.1). It seems like
> there ought to be scope for collapsing those datastructures somewhat but
> I'm not sure how yet.
>   

I wonder if libxl_device_model_info even needs to be exposed?  Generally
speaking, the domain config consists of

metadata (name, uuid, description, etc.)
basic resources (cpu, memory, maxmemory, etc.)
OS booting info (order, loader, kernel/ramdisk)
clock/timekeeping (clock offset, timer type, timer tick policy, etc.)
lifecycle controls (what to do on reboot, shutdown, crash, etc.)
devices (block, net, framebuffer, PCI, framebuffer, input, serial,
parallel, etc.)

All of the device model info can be inferred from this configuration.

BTW, thanks for the heads up on these changes.

Regards,
Jim

> The topologyinfo datastructure should be a list of tuples, not a tuple
> of lists.
>
> The API seems to expose a bunch of console related datastructures but
> not much in the way of functions to do anything with them. One of those
> must be wrong.
>
> I think IanJ wants to fixup the event API as well, it's a bit barking at
> the moment.
>
> IanJ is also going to be looking at the handling of storage backends, I
> expect that is moistly going to be internal to the library but it might
> have an impact on the API too.
>
>   
>>   Seems best for clients
>> to target new releases (4.1, 4.2, ...) and expect branch releases
>> (4.1.1, 4.1.2, ...) to have a stable API?
>>     
>
> That seems like a reasonable expectation to me.
>
> Ian.
>
>
>