Strings in Ocaml carry their own length. Absolutely nothing good can come
from having caml_string_length(data) be different to len.
Use the appropriate accessor, String_val(), but retain the workaround for the
Ocaml -safe-string constness bug in the same way as we've done elsewhere in
Xen.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Christian Lindig <christian.lindig@cloud.com>
In order to better reflect the contents of the header and to make it
more appropriate to use it for different runtime environments like
programs, libraries, and firmware, rename the libs.h include file to
common-macros.h. Additionally add a comment pointing out the need to be
self-contained.
Suggested-by: Andrew Cooper <andrew.cooper3@citrix.com>
Signed-off-by: Juergen Gross <jgross@suse.com>
Acked-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com> # tools/python/xen/lowlevel/xc/xc.c
Acked-by: Christian Lindig <christian.lindig@cloud.com>
Acked-by: Anthony PERARD <anthony.perard@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
caml_alloc() takes units of Wsize (word size), not bytes. As a consequence,
we're allocating 4 or 8 times too much memory.
Ocaml has a helper, Wsize_bsize(), but it truncates cases which aren't an
exact multiple. Use a BUILD_BUG_ON() to cover the potential for truncation,
as there's no rounding-up form of the helper.
Fixes: 8b7ce06a2d ("ocaml: Add XC bindings.")
Fixes: d3e649277a ("ocaml: add mmap bindings implementation.")
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Christian Lindig <christian.lindig@citrix.com>
This is not strictly necessary since it is essentially a no-op currently: a
cast to void * and value *, even in OCaml 5.0.
However it does make it clearer that what we have here is not a regular OCaml
value, but one allocated with Abstract_tag or Custom_tag, and follows the
example from the manual more closely:
https://v2.ocaml.org/manual/intfc.html#ss:c-outside-head
It also makes it clearer that these modules have been reviewed for
compat with OCaml 5.0.
We cannot use OCaml finalizers here, because we want exact control over when
to unmap these pages from remote domains.
No functional change.
Signed-off-by: Edwin Török <edvin.torok@citrix.com>
Acked-by: Christian Lindig <christian.lindig@citrix.com>
They are two competiting spelling for the variable holding the path to
"tools/ocaml", $(TOPLEVEL) and $(OCAML_TOPLEVEL). The "Makefile.rules"
which is included in all ocaml Makefiles have one rule which make use
of that variable which is then sometime unset. When building
"ocaml/xenstored", make isn't capable of generating ".ocamldep.make"
because $(TOPLEVEL) isn't defined in this case.
This can fail with an error like this when paths.ml have been
regenerated:
Error: Files define.cmx and paths.cmx
make inconsistent assumptions over interface Paths
This patch fix ".ocamldep.make" rule by always spelling the variable
$(OCAML_TOPLEVEL).
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Acked-by: Christian Lindig <christian.lindig@citrix.com>
configure checks just for ocamlc, but the tools in tools/ocaml depend
also on ocamlfind. On my workstation I have just ocamlc installed, but
no ocamlfind. As a result make will fail.
Update configure.ac to check also for OCAMLFIND, update various
Makefiles and replace hardcoded ocamlfind string with $(OCAMLFIND)
Please rerun autogen.sh after applying this patch.
Signed-off-by: Olaf Hering <olaf@aepfle.de>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Committed-by: Ian Campbell <ian.campbell@citrix.com>
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>