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] OCaml xenstored

To: Diego Ongaro <diego.ongaro@xxxxxxxxxx>
Subject: Re: [Xen-devel] OCaml xenstored
From: Patrick Colp <pjcolp@xxxxxxxxx>
Date: Wed, 16 Jul 2008 13:07:57 -0700
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Wed, 16 Jul 2008 13:08:27 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <487E3FAB.4050707@xxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <487E3D01.20601@xxxxxxxxx> <487E3FAB.4050707@xxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Thunderbird 2.0.0.14 (X11/20080622)
> I think you've overlooked to include a copyright statement or license.

Oops, thanks. Attached is the copyrighted and licensed version (GPL).


Just to make it clear, this is very much a work-in-progress and I've also added a TODO file outlining what I'm working on now (or will be soon). I posted before about some of the issues with the current XenStore daemon implementation. Unfortunately, this initial version of the OCaml daemon does not address most the concerns. However, it has improved the performance as now the store is an in-memory tree rather than a file-backed TDB.

The eventual goal is to have a safe and simple XenStore implementation that can run either as a dom0 process or in its own domain. The main issues I'm looking at fixing right now are transactions and supporting modularised security policies.


I found something interesting while developing. The original protocol specified that it is conventional that a node should not contain both data and children. In the proposed cleaned up protocol, I specified that this property should be enforced (not just conventional).

However, when I enforced it, I found that firing up xend would fail as there was a node that tried to have both data and children. I had to add a hack so that this would work. The guilty node is: /vm/image.

Here's an example dump of the vm subtree of XenStore just after xend has been run:

vm = ""
 00000000-0000-0000-0000-000000000000 = ""
  on_xend_stop = "ignore"
  shadow_memory = "0"
  uuid = "00000000-0000-0000-0000-000000000000"
  on_reboot = "restart"
  image = "(linux (kernel ))"
   ostype = "linux"
   kernel = ""
   cmdline = ""
   ramdisk = ""
  on_poweroff = "destroy"
  on_xend_start = "ignore"
  on_crash = "restart"
  xend = ""
   restart_count = "0"
  vcpus = "2"
  vcpu_avail = "3"
  name = "Domain-0"

I'm not sure if this problem occurs anywhere else, but I think ideally these would be fixed so that a node does in fact have only data or children, and never both.


Patrick


Diego Ongaro wrote:
Patrick Colp wrote:
I have completed my first version of said OCaml XenStore daemon, which
I've attached to this message. It contains the source files, Makefile,
and a README.

I think you've overlooked to include a copyright statement or license.
-Diego

Attachment: xenstored-ocaml.tar.bz2
Description: application/bzip

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
<Prev in Thread] Current Thread [Next in Thread>