Might be worth adding a ‘sync’ operation to the abstract signature, even if it doesn’t do anything with initial drivers I would find it useful if the comments clarified any general constraints/expectations on the size(s) of buffers for read and write, e.g. arbitrary length in bytes? Exactly one sector? Any multiple of sector size? A specific multiple of sector size? Up to any size? Cheers Chris From: cl-mirage-bounces@xxxxxxxxxxxxxxx [mailto:cl-mirage-bounces@xxxxxxxxxxxxxxx] On Behalf Of Anil Madhavapeddy
Sent: 21 November 2013 11:51
To: David Scott
Cc: Mirage List
Subject: Re: thoughts about block devices in Mirage 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.
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: 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): +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: 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): 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) --
Dave Scott
This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation.
|
