[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]

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:


To build this, run:

$ 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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.