Cannot be used in the toplevel

[samoht]

$ opam list xen-evtchn
# Available packages for 4.01.0:
xen-evtchn  1.0.6  Xen event channel bindings.

$ ledit ocaml
        OCaml version 4.01.0
# #require "xen-evtchn.unix";;
/home/vagrant/.opam/4.01.0/lib/ocaml/unix.cma: loaded
/home/vagrant/.opam/4.01.0/lib/bytes: added to search path
/home/vagrant/.opam/4.01.0/lib/bytes/bytes.cma: loaded
/home/vagrant/.opam/4.01.0/lib/lwt: added to search path
/home/vagrant/.opam/4.01.0/lib/lwt/lwt.cma: loaded
/home/vagrant/.opam/4.01.0/lib/lwt/lwt-log.cma: loaded
/home/vagrant/.opam/4.01.0/lib/ocaml/bigarray.cma: loaded
/home/vagrant/.opam/4.01.0/lib/lwt/lwt-unix.cma: loaded
/home/vagrant/.opam/4.01.0/lib/xen-evtchn: added to search path
# #require "xen-evtchn.unix";;/xen-evtchn/xen_evtchn.cma: loaded
Error: The external function `stub_evtchn_virq_dom_exc' is not available

I'm not sure how the current linking trick is supposed to work (ie. declaring the core lib as a dependency of the various stubs). I'm not sure how to fix this.

[raboof]

I'm running into this too - even when loading some modules without intending to do anything with mirage/xen.

Is there any workaround?

[talex5]

Same problem here. The main Eventchn module does:

external init': unit -> handle = "stub_evtchn_init"
external close': handle -> int = "stub_evtchn_close"

but it doesn't link against the C stubs. Only the .unix submodule does that. The Xen C stubs are still in mirage-xen (they should ideally be moved here).

However, moving the CSources to the main module gives:

Cannot load required shared library dllxen_evtchn_stubs.
Reason: /home/user/.opam/4.02.3/lib/stublibs/dllxen_evtchn_stubs.so: /home/user/.opam/4.02.3/lib/stublibs/dllxen_evtchn_stubs.so: undefined symbol: xc_evtchn_unbind.

Is there any way to replace libxenctrl with an OCaml version? Linking it seems to cause a lot of trouble...

[djs55]

libxenctrl does indeed cause a lot of trouble. My understanding of the
situation is: (this might be a little out of date, we'd have to ask on
xen-devel)

• the upstream xen project considers the protocol between libxenctrl and
  /dev/xen/evtchn to be private, and they want people to go via the C
  library
• the C library does not provide an ABI, but rather than API which implies
  that you need to recompile your sources with the new headers every time you
  upgrade the Xen version

I think the implications of this aren't commonly understood -- for example
you should rebuild qemu (a user of libxenctrl) every time you upgrade
xen just in case a struct field has moved around.

However, mitigating all that I also believe that the protocol hardly ever
changes. So I bet we could get away with a direct interface to
/dev/xen/evtchn in practice. If we did this and also volunteered to help
out upstream with any future protocol upgrades (through versioning logic or
something) then they might not mind too much. I think the main reason they
don't guarantee ABI compatibility is that it implies more work, and they
are already pretty busy.

On Mon, Jan 25, 2016 at 10:35 AM, Thomas Leonard notifications@github.com
wrote:

Same problem here. The main Eventchn module does:

external init': unit -> handle = "stub_evtchn_init"
external close': handle -> int = "stub_evtchn_close"

but it doesn't link against the C stubs. Only the .unix submodule does
that. The Xen C stubs are still in mirage-xen (they should ideally be
moved here).

However, moving the CSources to the main module gives:

Cannot load required shared library dllxen_evtchn_stubs.
Reason: /home/user/.opam/4.02.3/lib/stublibs/dllxen_evtchn_stubs.so: /home/user/.opam/4.02.3/lib/stublibs/dllxen_evtchn_stubs.so: undefined symbol: xc_evtchn_unbind.

Is there any way to replace libxenctrl with an OCaml version? Linking it
seems to cause a lot of trouble...

—
Reply to this email directly or view it on GitHub
#20 (comment).

Dave Scott