Re: [MirageOS-devel] thoughts about block devices in Mirage

[Anil Madhavapeddy <anil@xxxxxxxxxx>]

A 'sync' operation shouldn't be needed with the existing Block API, since
it's all guaranteed to be synchronous.

Thomas' combinator branch [1] gives us the ability to add transformers to
the various interfaces, and I anticipate one of the first ones will be a
buffer cache on top of the KV_RO. That cache will need to have the sync
operation.

Sector size still needs some more thought, though.  Dave, what's the state
of play with Xen blkfront sector sizes?  It seems to creeping up to 4096,
which is quite conveniently page-sized...

[1] https://github.com/mirage/mirage/pull/178

-anil

On Thu, Nov 21, 2013 at 02:38:19PM +0000, Christopher Greenhalgh wrote:
> 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.
> 
> -anil
> 
> On 20 Nov 2013, at 15:37, David Scott 
> <scott.dj@xxxxxxxxx<mailto: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
> 
> 
> 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.
> 
> 
> 
> 
> 
> 
> 
> 
> 

-- 
Anil Madhavapeddy                                 http://anil.recoil.org

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