[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [MirageOS-devel] xen event channels, grants, block devices etc
[cc:d xen-api since the event channel / grant code lives in xapi-project] 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:
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
_______________________________________________ MirageOS-devel mailing list MirageOS-devel@xxxxxxxxxxxxxxxxxxxx http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |