[Xen-devel] Re: ocaml?? why??

[Patrick Colp <pjcolp@xxxxxxxxx>]

Vincent Hanquez wrote:
> John Levon wrote:
>>> OCaml has been great to use. Programming the same functional tree
>>> store with advanced transaction merging capability in the C version
>>> would have been a major pain, compared to how (almost) easy it was in
>>> OCaml.
>>>     
>>
>> So, I'm interested: why?
>>   
> So now the reason, why not to modify the C version .. first getting rid
> of disk database to the memory, is quite annoying to do (but relatively
> easy so far) .. then you need to solve the problem of transaction stalling.
> there's lots of ways i guess, but i haven't imagine a solution where the
> same thing that the ocaml code does become trivial in C. either you need
> to modify every operation to understand some kind of modification list
> so that the tree get modified only at commit time (compare to now, at
> every operations), or you need to implement some kind of immutable tree
> (careful the C language doesn't prevent you for modifying it) which
> *requires* a GC that you need to implement too (or take one of those
> implementation from somewhere ..).

Not to mention the C version is a complete mess. I worked with it
previously to add XSM style security hooks. The policy and mechanism
were completely entangled, so this was not a trivial task. By the end of
it, there was an obvious conclusion to be draw: xenstored needed to be
re-written.

Beyond the source code itself, as Vincent points out, the old
transaction system was garbage. I wrote and released a DoS attack
earlier this year that brings the C xenstored to its knees (and
consequently Dom0).

When I implemented my version of XenStore in OCaml, I spent less than a
week to code together a ACID transactional system with "intelligent"
merging. In a nut-shell, it does per transaction copy-on-write of the
tree with some record keeping. Once a transaction is complete, it scans
the records to make sure nobody else has read a node that has been
modified by it then simply merges the copy-on-written version of the
tree into the original tree.

> there's lots of other small reasons too, like the static type system
> that protect a lot during development phase (xenstored is very annoying
> to test, since it requires for full testing, to reboot the machine), and
> it's still an asset when i need to prove that no unexpected type are
> going to appears somehow (try to do the same thing in python and have
> fun :).

This was a great win. Development was very quick due to the strong
typing of the language. Not to mention that this also makes the code
easier to understand and reason about. You can easily create immutables
(and I did so wherever possible) and know that they will never differ at
any point during execution than from when you created it. The same
cannot be said about C. A simple typo or pointer arithmetic mistake
somewhere and suddenly you have no idea what's going on and why your
program keeps crashing (or giving erroneous results).


> But surely xenstored could be implemented in any language, but I
> certainly wouldn't want to be the one fixing the C one, or implementing
> a python xenstored !

This is true as well, however as Ian pointed out, OCaml can be compiled
to native code and it is very easy to integrate it with C when needed.


Patrick

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