[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Xen-devel] Using the C library
It probably should be under /var/run since it is something that is only good for the curent xen kernel boot, and if Domain-0 dies, so does the box (I'm assuming that this is true, and if so, only a temporary situation) Personally I have a bias against interpreted languages. But that's just me. :) I have this thing about too many dependancies and unused chunks of bloat that aren't necessary, but are done in the name of "convenience" in final products. But this debate of preference is for another time/place. :) It's your project, you decide what it uses (deference only, no insult/attude intended). Why is it that everyone wants to use HTTP as a network connectivity base? It seems kind of semi-one-wayish to me. While it can do 2-way communication, it's stateless, and has a limit of the amount of "sent" data to the httpd without the special method of an uploaded "file" which takes you outside of the protocol itself.... I have to admit I'm no network protocol engineer, so I'm still learning a lot of the why/why-nots here. I'm probably missing out on a bunch of reasoning and well thought out logic.
On Sun, 20 Jun 2004 08:02:18 +0100 Ian Pratt <Ian.Pratt@xxxxxxxxxxxx> said...
> *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