[Xen-API] xen event channels, grants, block devices etc

[David Scott <scott.dj@xxxxxxxxx>]

[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@xxxxxxxxxxxxx
http://lists.xen.org/cgi-bin/mailman/listinfo/xen-api