hsXenCtrl is the Haskell bindings to Xen Control (see <xenctrl.h> if you have the xenctrl-devel package installed).
2 Current Status
Most of xenctrl.h has c bindings made for it in the System.Xen.CBindings module. The API is subject to change as new types gradually replace primitives (such as CInt all over). In most cases there exists a Storable instance for the Haskalized structures; one notable exception is MMUExtOp (mmuext_op_t) which has unions and thus would need extra context for a proper peek operation.
The first stage of development is making System.Xen.CBindings, in which an FFI binding is made to all C routines in xenctrl.h and supporting data structures are translated into Haskell. Little to no logic is intended to be implemented in this module - it should give uninhibited access to the xen primitives.
A higher level module, System.Xen, will be made that provides most the basic operations in a simpler manner. The need to call xc_handle_[open,close] will be in the plumbing along with any need for XCHandle. Also, the errors (typically returned CInt values) will be reexpressed using 'Either XenError a' or by throwing exceptions (the library will pick a single method).
4 Suggested Projects Using hsXenCtrl
The most obvious doors opened are Haskell rewrites of the current Xen infrastructure (virt-install, xm, xend). Slightly more interesting tasks could be (warning: random thoughts):
- HAPPS server that can manage Xen domains (without requiring python libs or System.cmd)
- Network or BSD socket based remote management programs in Haskell. haxr or session-types might be of use here.
- With the functions that can alter the CPUs availability, more complex rules or sharing arrangements could be implemented. Same concept applies to other resources such as PCI and memory allocation.
I'll add to the bindings as I find time. If you have time and are eager then feel free to start designing and implemented System.Xen - if you don't then I will, just not on any particular timeline.