Re: [Xen-devel] 3.0.3 freeze

[Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>]

On 28/8/06 4:49 pm, "Daniel Veillard" <veillard@xxxxxxxxxx> wrote:

>> All bug fixing is going on in the unstable tree: there has been no fork. I'm
>> now done with major refactorings (domctl/sysctl on Friday; shadow2->shadow
>> today). I wanted those in before 3.0.3 because, although large, they are
>> unlikely to break anything,
> 
>   Huh ? libvirt uses dom0 syscalls. And libvirt uses its own code to do it
> since the existing libraries for dom0 calls are GPL'ed which would not be
> compatible with libvirt own licencing (LGPL). The headers used by libvirt
> are simply removed, the ioctl entry points are changed, etc ... You really
> expected that to 'not break anything' ?

API/ABI compatibility is not guaranteed at the low-level control-plane
interfaces: that is instead provided at the XML-RPC level (and, practically
speaking, the libxenctrl/libxenguest interface is pretty stable too). By 'no
breakage' I mean that the new interfaces work fine with a matching set of
the supported libraries libxenctrl and libxenguest.

>  +#define XEN_DOMCTL_getdomaininfo     5
> 
>  +#define XEN_SYSCTL_getdomaininfolist 6
> 
> Can you explain why listing one domain info is a control operation (subject
> to changes) and listing multiple domain info in a nearly identical way is a
> system operation (and supposedly slightly more stable from now on).

Neither of the above interfaces (sysctl/domctl) has guaranteed ongoing API
or ABI compatibility. The new platform_op interface, used by dom0 kernel, is
the only new hypercall for which we will guarantee ongoing stability.

The two commands you refer to are in different hypercalls because one is
specific to a particular domain (hence domctl) while the other is a request
for 'system-wide' info about all domains (hence sysctl).

> Was any HV call removed, or did they were all split between the 3 new sets ?

None were removed. They've simply been reassigned as sysctls or domctls to
rationalise the API.

>   The proper way in my opinion is to not break the hypercalls, if you need
> changes in extensions and semantic, create new calls ! It is possible to
> make graceful evolution of APIs, otherwise none of the software you are
> using right now to read this mail would simply be possible.

We guarantee compatibility for *all* our other interfaces. The Xen
management API is also being stabilised, but at the XML-RPC level.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel