|  |  | 
  
    |  |  | 
 
  |   |  | 
  
    |  |  | 
  
    |  |  | 
  
    |   xen-devel
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.
Ian
-------------------------------------------------------
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
Xen-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/xen-devel
 | 
 |  | 
  
    |  |  |