Re: [MirageOS-devel] Mirage tracing status

[David Scott <scott.dj@xxxxxxxxx>]

On Mon, Dec 8, 2014 at 11:05 PM, Anil Madhavapeddy <anil@xxxxxxxxxx> wrote:

On 8 Dec 2014, at 10:48, Thomas Leonard <talex5@xxxxxxxxx> wrote:

> Building support for reading from a Xen guest requires xenstore
> support, which is also difficult to build (requires Xen headers), so
> that needs to be optional too.

Dave might comment on this -- you shouldn't need the Xen headers
to build a simple Xenstore client. Maybe its the gnttab driver?

A simple Xenstore client shouldn't need the Xen headers in theory, although the current package might have an accidental dependency. As part of my yak shaving^W^Wimproving the Xen driver code I've been

- functorising the core logic (e.g. of vchan) to remove any hard-coded Xen (or OS.) dependency

- splitting the Xen kernel and Xen userspace implementations into separate sub-packages (I noticed that I also had to move the code into different source directories to make this work -- perhaps I confused OASIS?)

So far I've

- split xen-evtchn

- split xen-gnt

- functorised and split vchan

- functorise the Xenstore client (now has a nicer interface IMHO)

- functorised and split shared-memory-ring

This allows a vchan Unix CLI to build and run on OS X. I've still got to

- functorise and split mirage-net-xen (in progress)

- functorise and split mirage-block-xen

- teach the mirage tool how to instantiate the new functors

Hopefully the mirage tool will be able to generate code like

module XS = Xenstore.Client.Make(Xenstore_kernel_ring)

 (* where Xenstore_kernel_ring calls C stubs to get the ring and evtchn number *)

module Block = Xenblock.Front.Make(Kernel_grants)(Kernel_events)(Xenblock.ConfigureFrom(XS))

The names of the modules and functors are a bit up-in-the-air. In particular I'm torn whether to use the Xen-jargon "Front(end)" and "Back(end)" everywhere or to just do what vchan does and use the more common terms "Client" and "Server".

When this refactoring is done one of the nice things that falls out is a very easy way to write a dom0 daemon which watches Xenstore for domains arriving and leaving and connects to them (via vchan or console, whichever we like) and which could be the simple heart of an entropy daemon.

Cheers,

Dave

_______________________________________________
MirageOS-devel mailing list
MirageOS-devel@xxxxxxxxxxxxxxxxxxxx
http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel