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