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