[cc:d xen-api since the event channel / grant code lives in xapi-project] Hi,
I've completed the refactoring I mentioned on the mirage call this afternoon. I've removed the package conflicts between mirage-xen and xenctrl over the virtual package "xenctrl". As a result the packages can be installed in parallel and you can choose between Unix and Xen at application final link-time. If you see any library depend on "xenctrl" or 'xen-event" or "xen-grant", these should be changed to 'xen-evtchn" and "xen-gnt". A Xen application can be built with the "mirage" tool as normal: all the Xen stubs are still in the mirage-xen package. A Unix application which wants to implement a Xen block device (e.g. if you want to boot a regular VM from some fancy new storage type) needs to link with the stubs in the packages: "xen-evtchn.unix" "xen-evtchn.unix.activations" "xen-gnt.unix". For an example of this see: https://github.com/mirage/xen-disk To build this, run: $ opam init git://github.com/mirage/opam-repository#mirage-1.1.0 $ opam install xen-disk NB: I think I'm hitting an opam 1.1.0-beta bug where "mirage-types" optionally depends on "lwt & ipaddr"; some other package depends on "lwt"; but "ipaddr" is not being demanded. Anyone else seeing this? Perhaps I've misunderstood the meaning of depopts in opam. A workaround is just to install "ipaddr" first. Just to demonstrate that a Mirage Xen kernel can still be built with no conflict: $ opam install mirage $ git checkout git://github.com/avsm/mirage-skeleton $ cd mirage-skeleton/basic $ mirage configure --xen $ mirage build $ sudo xl create -c console.xl Cheers, -- Dave Scott
_______________________________________________ Xen-api mailing list Xen-api@lists.xen.org http://lists.xen.org/cgi-bin/mailman/listinfo/xen-api
