Re: [Xen-devel] 3.0.3 freeze - Daniel Veillard - com.xensource.lists.xen-devel

27 messages in com.xensource.lists.xen-develRe: [Xen-devel] 3.0.3 freeze

From	Sent On	Attachments
Ian Pratt	22 Aug 2006 09:03
Sean Dague	22 Aug 2006 09:33
Ryan Harper	22 Aug 2006 14:00
Subrahmanian, Raj	22 Aug 2006 14:11
Tuan Van	24 Aug 2006 17:53
Daniel P. Berrange	28 Aug 2006 07:58
Keir Fraser	28 Aug 2006 08:07
Daniel P. Berrange	28 Aug 2006 08:20
Ian Pratt	28 Aug 2006 08:21
Daniel Veillard	28 Aug 2006 08:48
Keir Fraser	28 Aug 2006 09:31
Rik van Riel	28 Aug 2006 09:47
Keir Fraser	28 Aug 2006 09:48
Ian Pratt	28 Aug 2006 09:48
Daniel P. Berrange	28 Aug 2006 10:02
Rik van Riel	28 Aug 2006 10:12
Keir Fraser	28 Aug 2006 10:19
Daniel Veillard	28 Aug 2006 10:55
Daniel Veillard	28 Aug 2006 13:16
Anthony Wright	12 Sep 2006 04:06
Ian Pratt	12 Sep 2006 04:40
Anthony Wright	12 Sep 2006 05:55
Matt Ayres	12 Sep 2006 06:45
John Lenz	12 Sep 2006 14:59
Nicholas Lee	13 Sep 2006 02:32
Anthony Wright	19 Sep 2006 04:20
Keir Fraser	19 Sep 2006 05:56

Subject:	Re: [Xen-devel] 3.0.3 freeze
From:	Daniel Veillard (veil...@redhat.com)
Date:	08/28/2006 10:55:46 AM
List:	com.xensource.lists.xen-devel

On Mon, Aug 28, 2006 at 05:32:01PM +0100, Keir Fraser wrote:

On 28/8/06 4:49 pm, "Daniel Veillard" <veil...@redhat.com> 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

Seriously, which one ? The one about to be deprecated or the one which doesn't exist yet ? There is in practice no API/ABI here, only the sxp of xend can be considered a stable ABI so far, but that's slated for removal. Stable doesn't mean a 6 month time span for us, really.

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.

Which I can't use due to Licence issues, they are still GPL if I'm not mistaken. And anyway they won't even work on 3.0.2 on x86_64 because the HV ABI broke in the meantime.

+#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.

Okay, that mean we will have to work around the changes for the foreseeable future. You don't care about being stable there, we do, at least now I complained publicly about it. I have reason why I care for those, we explained them. I don't know why you don't want to garantee anything at that level. I know that non stable kernel interfaces can change, that's a fact of life, but things can be handled gracefully and nicely, it's also possible to be uncooperative on purpose, I hope it is not the case.

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).

Okay

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.

Okay thanks, it's not easy to track down because that was dispatched on multiple files now.

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.

And the level of CPU consumption used just for monitoring was not acceptable last we checked, only the hypercalls allowed decent performances.

Daniel