*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?
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).
Sorry to ask for details instead of hunting them down myself. I'm kind of
swamped over the last 3 weeks and the coming 3 weeks due to moving into a new
house instead of living in the warehouse. 8-)
Brian
On Sat, 19 Jun 2004 07:10:42 +0100
Ian Pratt <Ian.Pratt@xxxxxxxxxxxx> said...
> What was the reasoning behoind going to a userland daemon in Domain-0 to
> handle tracking of resources? I'm not terribly familiar with the logic behind
> this method other than instabilities int he daemon keeps you from crashing
> the kernel. But if you crash the userland daemon, how do you recover the lost
> information?
The dom0 daemon stores the state of the world in the file
system. The daemon is actually restartable: when it starts it
checks to see whether the domains it has state for still exist,
and if so, readopts them.
The control plane software was becoming quite complex, so it was
clear to us that we needed to do this in a daemon rather than add
a whole lot of extra complexity into Xen. We could have still
held all the state in Xen, and have the daemon read it out on
reboot. However, in the new IO world Xen simply didn't know
about a domain's IO configuration. We could have simply copied
that information into Xen for safe keeping, but adding extra
complexity to Xen didn't seem to make sense. Storing the state
in the dom0 file system seemed like a good compromise, and Mike's
recently added code to make the daemon restartable (which is very
useful for debugging anyhow)
> Another question I had was, why python (I don't intend to start a flamewar of
> lang-x vs lang-y). Most system level tools that I have seen in the last 14
> years of using unix were written in C.
In my view, It's pretty hard to justify doing anything userland
in C these days. I'd certainly stand by the decision to use
python -- we wouldn't have achieved the same rapid development
and decent robustness in C.
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