[MirageOS-devel] refactoring Xen drivers

[Dave Scott <Dave.Scott@xxxxxxxxxx>]

Hi,

Iâd like to make the Xen drivers easier to test and more flexible, so we can 
re-use some of the protocols for IPC under Unix. Iâd also like to remove the 
âlinking hackâ where we avoid functorising the drivers in OCaml by choosing 
from alternative C stubs at link-time, thereby losing some of the safety weâd 
have now if we had just stuck with OCamlâ

Anyway, Iâve prototyped changes to xen-evtchn[1] and xen-gnt[2]. They now have 
the following ocamlfind structure:

xen-evtchn: pure OCaml definitions, including an âEVENTSâ signature
xen-evtchn.xen: an implementation of âEVENTSâ which runs in Xen kernels
xen-evtchn.xenctrl: an implementation of âEVENTSâ which uses /dev/xen/evtchn
xen-evtchn.unix: an implementation of âEVENTSâ which uses Unix domain sockets
xen-evtchn.inheap: an implementation of âEVENTSâ which uses Lwt_condition.t

xen-gnt: pure OCaml definitions, including a âMEMORYâ signature
xen-gnt.xen: an implementation of âMEMORYâ which uses mini-os grant tables
xen-gnt.xenctrl: an implementation of âMEMORYâ which uses gntdev/gntshr
xen-gnt.unix: an implementation of âMEMORYâ which uses mmap(2)
xen-gnt.inheap: an implementation of âMEMORYâ which uses Hashtbls full of 
buffers

So now a typical Xen driver, such as vchan[3], can be a functor over EVENTS and 
MEMORY, permitting multiple implementations. For example there is an example 
CLI which uses the vchan protocol between two Unix processes (e.g. on OS X) â 
no Xen headers required:

https://github.com/djs55/ocaml-vchan/blob/refactor-modules/README.md

  $ ./unixcat.native -l 2 foo
  XEN_ROOT=/tmp/unixcat.native.28585.0; export XEN_ROOT;
  XEN_CONFIGURATION="((ring_ref 0) (event_channel 
/tmp/unixcat.native.28585.0/0))"; export XEN_CONFIGURATION

Iâm planning on functorising shared-memory-ring over these signatures so weâll 
be able to run netback/netfront and blkback/blkfront between Unix processes 
(and test them more while weâre at it). The âmirageâ tool could generate the 
appropriate functor application depending on the target platform.

Once weâve sorted out the ability to build C stubs for Mirage/Xen, then we can 
move the C stubs from mirage-platform to xen-{evtchn,gnt}.xen, which will make 
everything look a lot more normal.

Let me know what you think,
Dave

[1] https://github.com/djs55/ocaml-evtchn/blob/refactor-modules/lib/s.mli#L17
[2] https://github.com/djs55/ocaml-gnt/blob/refactor-modules/lib/s.mli#L17
[3] https://github.com/djs55/ocaml-vchan/blob/refactor-modules/cli/xencat.ml#L21
    
https://github.com/djs55/ocaml-vchan/blob/refactor-modules/cli/unixcat.ml#L20
_______________________________________________
MirageOS-devel mailing list
MirageOS-devel@xxxxxxxxxxxxxxxxxxxx
http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel