This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


[Xen-tools] Re: [Xen-devel] [PATCH][RFC] xenstat framework and vm-top

To: Anthony Liguori <aliguori@xxxxxxxxxx>
Subject: [Xen-tools] Re: [Xen-devel] [PATCH][RFC] xenstat framework and vm-top
From: Mark Williamson <mark.williamson@xxxxxxxxxxxx>
Date: Tue, 16 Aug 2005 01:41:24 +0100
Cc: xen-tools@xxxxxxxxxxxxxxxxxxx, Michael Running Wolf <rngwlf@xxxxxxxxxx>, Judy Fischbach <jfisch@xxxxxxxxxx>
Delivery-date: Tue, 16 Aug 2005 00:39:47 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <430133E0.2030407@xxxxxxxxxx>
List-help: <mailto:xen-tools-request@lists.xensource.com?subject=help>
List-id: Xen control tools developers <xen-tools.lists.xensource.com>
List-post: <mailto:xen-tools@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-tools>, <mailto:xen-tools-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-tools>, <mailto:xen-tools-request@lists.xensource.com?subject=unsubscribe>
References: <1124147277.680.91.camel@xxxxxxxxxxxxxxxxxxxxx> <1124150244.22835.19.camel@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <430133E0.2030407@xxxxxxxxxx>
Sender: xen-tools-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: KMail/1.8
> >First of all, I agree that we don't want to support yet another API.

Do we have a policy on compatibility in the tools?  The Xen / backends ABI is 
obviously sacred but is userspace control plane stuff also included...?

> >I'd like to point out, however, that applications being built to manage
> >xen systems in a clustered environment - whether through CIM, XML-RPC,
> >or what have you - will need an API to query this information rather
> >than invoking commands like xentop/vm-top or xm.
> Yeah, there's a bit more we're probably going to need too beyond just
> the info provided by libxenstat.  We'll have to identify those things
> and then (perhaps using libxenstat as a base) build an API (assuming we
> can't get the store to contain that function by then).

I think libxenstat might as well be kept as a base for this work...  IMHO, it 
should at least stay separate in the source for now.  vm-top / xentop could 
be statically linked with it for now, OR it could be stashed 
under /usr/lib/xen/lib, depending on ABI issues.

> >>2) rename vm-top to xentop
> >>3) install xentop to /usr/lib/xen/xentop
> >>4) add xm top that invokes /usr/lib/xen/xentop

Regarding the tool naming: xentop probably makes more sense, I guess.  I 
hadn't thought of invoking it from xm but it's probably sensible as this'll 
match up with the model used by other tools.


Xen-tools mailing list