WARNING - OLD ARCHIVES

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/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-tools

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

On Mon, 2005-08-15 at 20:05 -0500, Anthony Liguori wrote:
> Mark Williamson wrote:
> 
> >>>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'll put in my vote that the userspace library API should be held to the 
> same standards as the hypervisor ABI.
> 
> In reality, there won't be more than a dozen guest ports to Xen (for 3.0 
> at least).  There will likely be dozens of tools written that use the 
> userspace API though.



I think it's a good idea to lock down the User Space API so applications
will have a stable interface to build upon. The API can buffer
applications from the change underneath. The functions for maintaining a
Xen system won't change as much - create, destroy, save, etc. - while
how they are implemented could change. 


> >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.
> >  
> >
> I'd be happier linking against it statically.  I really like having 
> simple code though.  What does everyone else think?


I think libxenstat could be extended to be the stable User Space API,
perhaps not for 3.0 but definitely for the following release. Would it
be more useful to leave it available in the tree for the management
applications that will be built to 3.0 and thereby also being a first
step toward the 3.1 stable interface? Or would it be more useful to
statically link it and not expose it for 3.0 applications? 

The point is - management applications will be written for 3.0,
regardless whether there's a stable defined API or not. Wouldn't it be
more useful to give them access to libxenstat? Especially since we could
use it as a base for the stable API? 

Thanks,

Dan


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