[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] Using the C library

> *nod* makes sense on the daemon.  It's the same method that LVM used to use 
> vgscan for. It would store stuff in /etc/lvm.d/<vg_name>.
> Where are you storing things from xend?  

It's currently under/etc/xen/xend. I wander whether it should be
moved under /var ?

> Would you have any objections to having an extended C library for performing 
> common tasks such as the xc_dom_control, xc_physinfo, and xc_dom_create for 
> inclusin into system management programs that are written in C/C++? Something 
> like say xccontrol lib? If you have an existing procedure of checks and 
> commands in python, it shouldn't be too hard to then write the same logic in 
> C for people that prefer to have a minimalized system (eg no interpreted 
> languages in Domain_0). 

The main way we envisage "3rd party" system management tools
controlling a Xen node is via xend's RPC over HTTP[S] interface.

If you're determined not to have any python in domain 0, it would
obviously be possible to write a minimal daemon in C. You should
think hard about whether its worth the effort...

I've just had a look on one of our systems and xend has a resident
memory size of just over a megabyte. The python interpreter's RSS
is about half a MB. The virtual memory size is rather bigger, but
that doesn't cost anything.


This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND
Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.