[Ocaml-reins-devel] Fedora - Several questions

[Richard W.M. J. <rj...@re...>]

I made a Fedora package.  The tracking bug for review and inclusion is
here:

  https://bugzilla.redhat.com/show_bug.cgi?id=460732

I have several questions related to this:

(1) Current, first and only version is '0.1a'.  The 'a' is a problem
for Fedora because it's ambiguous whether the next version could be
'0.1b' or '0.1'.  Ideally it'd be good if the next version was '0.2'
and we could just drop these letters altogether :-)  What will the next
verison be?

(2) When is the next release likely?  Are there outstanding patches
queued up for reins?  (I don't see much activity on the mailing list).

(3) I frequently need a structure called a Segment Tree to represent
ranges of memory addresses with holes.  (Or rather, I need to
represent ranges of memory addresses with holes, and for that I've
implemented a Segment Tree).

      <--- range1 --->             <--- range2 --->
                                            <--- range3 --->
  |   |              |             |        |              |        |
  0  100            200           300      350            450      500

  Operations:
  (i) Fast map from address to byte in range at address or hole.
  (ii) Fast searches.
  (iii) If a new range overlaps an old one, then it obscures the old
    range at overlapping addresses.  (This is currently a slow operation
    because we rebuild the segment tree).

I don't see anything suitable in Reins which can be used to implement
this, but then I'm not familiar with all of the structures -- could
one be used to implement this?

If not, then I offer this implementation:
  http://et.redhat.com/~rjones/virt-mem/html/Virt_mem_mmap.html
  http://hg.et.redhat.com/virt/applications/virt-mem--devel/?f=83a8b07174fd;file=lib/virt_mem_mmap.ml
  http://hg.et.redhat.com/virt/applications/virt-mem--devel/?f=265dfb7410c9;file=lib/virt_mem_mmap.mli
  http://hg.et.redhat.com/virt/applications/virt-mem--devel/?f=51c08794adc0;file=lib/virt_mem_mmap_c.c

Now this implementation isn't suitable for inclusion in Reins at the
moment.  The particular problems with it are as far as I'm concerned:

 (a) Over-complex yet rather inflexible.
 (b) Needs to work with an unsigned int64 range, but currently the
   range is signed so it breaks with addresses > 0x7fffffff_ffffffff.
 (c) Includes C code, which is really necessary for getting the kind of
   speed we require from searches.

On the other hand, it is persistent ...

So, any comments on whether I can either reimplement this in terms of
another Reins structure, or if a properly functorized segment tree is
a good candidate for inclusion in Reins?

Rich.

-- 
Richard Jones, Emerging Technologies, Red Hat  http://et.redhat.com/~rjones
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://et.redhat.com/~rjones/virt-top