WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] Using the C library

To: brianw@xxxxxxxxxxxx
Subject: Re: [Xen-devel] Using the C library
From: Ian Pratt <Ian.Pratt@xxxxxxxxxxxx>
Date: Sat, 19 Jun 2004 07:10:42 +0100
Cc: Ian Pratt <Ian.Pratt@xxxxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxxx, Ian.Pratt@xxxxxxxxxxxx
Delivery-date: Sat, 19 Jun 2004 07:12:29 +0100
Envelope-to: steven.hand@xxxxxxxxxxxx
In-reply-to: Your message of "Sat, 19 Jun 2004 02:30:14 CDT." <E1BbXUZ-0003qR-6T@xxxxxxxxxxxxxxxxxxx>
List-archive: <http://sourceforge.net/mailarchive/forum.php?forum=xen-devel>
List-help: <mailto:xen-devel-request@lists.sourceforge.net?subject=help>
List-id: List for Xen developers <xen-devel.lists.sourceforge.net>
List-post: <mailto:xen-devel@lists.sourceforge.net>
List-subscribe: <https://lists.sourceforge.net/lists/listinfo/xen-devel>, <mailto:xen-devel-request@lists.sourceforge.net?subject=subscribe>
List-unsubscribe: <https://lists.sourceforge.net/lists/listinfo/xen-devel>, <mailto:xen-devel-request@lists.sourceforge.net?subject=unsubscribe>
Sender: xen-devel-admin@xxxxxxxxxxxxxxxxxxxxx
> 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