OCaml xenstored

OCaml xenstored

[Patrick Colp]

[-- Attachment #1: Type: text/plain, Size: 981 bytes --]

Hello all,

About six weeks ago I posted about making changes to XenStore. I suggest 
a cleaned up XenStore protocol and said I would begin work on an OCaml 
version of the XenStore daemon.

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.

The core functionality of the original XenStore daemon is in place. Some 
of the trace file and logging stuff may not be quite fully implemented, 
but it does allow domains to be started, shutdown, and migrated.

The code is ugly and all in one file. But this was my first time ever 
coding in OCaml as well. I'm currently working on cleaning up the code 
and moving it into modules (and the new code is starting to look *much* 
nicer than what I'm posting here). This next version should also include 
some enhancements to things like transactions and security.

Please let me know of any problems/suggestions you have.


Patrick

[-- Attachment #2: xenstored-ocaml.tar.bz2 --]
[-- Type: application/x-bzip, Size: 20680 bytes --]

[-- Attachment #3: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Re: OCaml xenstored

[Joshua West]

Not that I necessarily object, but I'm wondering why you chose OCaml for
a new xenstored, instead of the languages already native to Xen like
Python and C?

Patrick Colp wrote:
> Hello all,
>
> About six weeks ago I posted about making changes to XenStore. I
> suggest a cleaned up XenStore protocol and said I would begin work on
> an OCaml version of the XenStore daemon.
>
> 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.
>
> The core functionality of the original XenStore daemon is in place.
> Some of the trace file and logging stuff may not be quite fully
> implemented, but it does allow domains to be started, shutdown, and
> migrated.
>
> The code is ugly and all in one file. But this was my first time ever
> coding in OCaml as well. I'm currently working on cleaning up the code
> and moving it into modules (and the new code is starting to look
> *much* nicer than what I'm posting here). This next version should
> also include some enhancements to things like transactions and security.
>
> Please let me know of any problems/suggestions you have.
>
>
> Patrick
> ------------------------------------------------------------------------
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>   


-- 
Joshua West
Systems Engineer
Brandeis University
http://www.brandeis.edu

Re: OCaml xenstored

[Diego Ongaro]

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

Re: OCaml xenstored

[Patrick Colp]

[-- Attachment #1: Type: text/plain, Size: 2330 bytes --]

 > 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 #2: xenstored-ocaml.tar.bz2 --]
[-- Type: application/x-bzip, Size: 27454 bytes --]

[-- Attachment #3: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Re: OCaml xenstored

[Ian Jackson]

Patrick Colp writes ("Re: [Xen-devel] OCaml xenstored"):
> 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).

That protocol document (docs/misc/xenstore.txt) is a retrospective
view written quite recently by me.  When I say there that something is
`conventional' what I mean is that new code should do as suggested.

Much old code does different things and sadly it is necessary to
retain compatibility with a lot of it.

Unfortunately we don't have a useful and up to date document
describing the format and semantics of the tree of data in xenstore.

Ian.