ocamlfind does not support namespaces, so to avoid
name clashes the module names have become longer.
Additionally, the xenstore and xenbus subdirs, which
contain several modules each, have been packed into
toplevel Xenstore and Xenbus modules.
xb becomes xenbus, xc becomes xenctrl, xl becomes xenlight,
xs becomes xenstore, eventchn becomes xeneventchn and
mmap becomes xenmmap.
[ Patch modified from that submitted, to update the .hgignore, and to
cope with intervening changes to mmap_stubs.c -iwj ]
Signed-off-by: Jon Ludlam <jonathan.ludlam@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
Change GET_C_STRUCT to Intf_val to follow the common naming scheme of
OCaml macros, and for better readability.
Signed-off-by: Zheng Li <dev@zheng.li>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
Fix invalid memory access in OCaml mmap library (to play nicely with the GC)
This was a bug reported by Roberto Di Cosmo. When he tried to reuse
the mmap library for his own project, Mmap.read occasionally got
different result when reading from the same map. This turned out to be
a bug in the binding, where a C pointer was created pointing to a
OCaml value, and the OCaml value was subsequently moved around by the
GC after memory allocation and hence invalidated the C pointer. This
patch removes the indirection of C pointer and uses OCaml macro to
access values directly.
Only Mmap.read function had this problem. The other functions, despite
having the same code style, didn't have memory allocation involved
hence wouldn't intrigue such an error. I've changed all of them to the
safer style for future proof. Directly casting OCaml value's *data
block* (rather than the value itself) as a C pointer is not a common
practice either, but I'll leave it as it is.
The bug hadn't occured on XenServer because XenServer didn't make use
of the Mmap.read function (except in one place for debugging). In
XenServer, most mmap operations were going through another pair of
separately implemented functions (Xs_ring.read/write).
Signed-off-by: Zheng Li <dev@zheng.li>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
Otherwise make can search the path relative to certain standard paths
such as /usr/include (e.g., the line '-include $(XEN_ROOT)/.config' in
Config.mk suffers from this).
Signed-off-by: Keir Fraser <keir@xen.org>
Previously the install target was having no effect because it ended up
calling the default target in the subdir Makefile instead of the
install target.
Resolve this by tying the tools/ocaml Makefiles into the generic
handling done by tools/Rules.mk.
Other changes arising in one way or another from this:
- Add libs/xl/META.in
- Update .hgignore for META files
- Create leading directories
- Remove existing module before installation in install targer
(worksaround what appears to be a quirk of "ocamlfind install")
- Use the globally defined $(DESTDIR)
- Move "ocamlfind printfconf destdir" to a common variable,
repurposing exising unused OCAMLDESTDIR, incorporating $(DESTDIR) at
the same time.
- Drop a few unused variabe definitions (mainly to avoid deciding if
$(DESTDIR) made sense for them or not.
- Pass -destdir to ocamlfind in uninstall target for symmetry with
install target.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
This is quite similar to the mmap functionality available in bigarray
but it's less complicated.
Signed-off-by: Vincent Hanquez <vincent.hanquez@eu.citrix.com>
Jon Ludlam
Zheng Li
Keir Fraser
Ian Campbell
Keir Fraser