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