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
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> 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_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel