Re: thoughts about block devices in Mirage

[Anil Madhavapeddy <anil@xxxxxxxxxx>]

This all looks right to me.  I've merged in most of them (except xen-block-driver; made a few minor comments on the pull req).

I'm coming around to the idea that the dynamic device registration is generally a good idea rather than a pure Mirari-generator, since it covers hotplug too, and makes development much easier (less boilerplate code to generate).

I'm currently porting the Release framework to work as a non-root user, which will give us an IPC-capable, privdropping Unix backend.  I'll hook in a block device message to dynamically "hotplug" new block devices into the Unix backend too.  This is useful both for testing and for production use in Unix, since it allows incoming file descriptors to be sandboxed more easily using frameworks such as Capsicum on FreeBSD.

-anil

On 20 Nov 2013, at 15:37, David Scott <scott.dj@xxxxxxxxx> wrote:

Hi,

I've been trying to tidy up the mirage block device interface before the big release. I've added a signature BLOCK to mirage-types:

https://github.com/mirage/mirage-types/blob/master/lib/v1.ml#L124

This has notions of

* an active/ open device

* a blocking I/O action

* a page aligned buffer

and allows you to read and write from/to a set of buffers.

I've proposed a less-abstract version of the signature in mirage-platform/xen (but it should be common to both unix and xen):

https://github.com/mirage/mirage-platform/pull/73/files

which looks like this:

 +module type S = V1.BLOCK_DEVICE

 +  with type page_aligned_buffer := Cstruct.t

 +  and type 'a io := 'a Lwt.t

together with a lookup table mapping driver names (strings) to (module S) instances. Does this seem like a reasonable approach?

In my xen block driver I've added support for this interface and left the old code for backwards compat:

https://github.com/mirage/ocaml-xen-block-driver/pull/8

The idea is the block driver will automatically register itself as a driver called "local". A Unix version could do the same. We could add things like "iscsi" later.

Finally I've proposed some test cases for mirage-skeleton which check various read/write operations seem to be working (and failing when they should be failing etc):

https://github.com/mirage/mirage-skeleton/pull/15

Let me know what you think. The next step would be to get this new interface working on Unix and then to start working on a filesystem interface (for those who like that sort of thing)

Cheers,

--
Dave Scott