[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. 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
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |