Re: requests for clarification

[Anil Madhavapeddy <anil@xxxxxxxxxx>]

On Thu, Dec 22, 2011 at 01:08:18PM +0000, Christopher Greenhalgh wrote:
> Thanks. 
> 
> So in terms of application persistence (with writing), it looks like the
> only 'portable' option is Blkif, and the only Read/write abstraction
> over that at the moment is the FAT filesystem?

Thats right... the FAT filesystem 'should work' but its mainly been tested
for read-only but read-write might still be buggy. I'll let Dave comment
on that...

> (the direct version of simpleKV runs over a Blkif, with its own format,
> but is readonly; the socket version of simpleKV uses the UNIX native fd
> interface directly over a host directory, rather than the unix version
> of the Blkif which runs over a single file)
> 
> So if I want something else I write my own persistence over Blkif? Or
> are there some other chunks of code sitting around that would be a
> better starting point?

You could also extend the KV_RO into a KV_RW version that passes through
the write call to the socket. However, at this stage it might be easier to
just persist via a call to a remote service (like an Amazon S3 call or
something). Depends how much hacking you feel like doing on Mirage really!

-anil

> 
> Cheers
> Chris
> 
> 
> 
> -----Original Message-----
> From: Anil Madhavapeddy [mailto:anil@xxxxxxxxxx] 
> Sent: 21 December 2011 23:29
> To: Christopher Greenhalgh
> Cc: cl-mirage@xxxxxxxxxxxxxxx
> Subject: Re: requests for clarification
> 
> On Tue, Dec 20, 2011 at 12:14:51PM +0000, Christopher Greenhalgh wrote:
> > I thought I'd use some of the vacation to try to get up to speed a bit 
> > with mirage, and have a few questions and a couple of tutorial 
> > comments so far...
> 
> Splendid! It's worth an initial note on where we are, since there's been
> quite a bit of background hacking recently towards various papers, and
> not all of it is merged yet.
> 
> We've patched together a fairly complete protocol stack, but found a few
> deficiencies in the process:
> 
> - Bitstrings are very efficient to read in a zero-copy fashion, but writing
>   constructs many small strings that are copied several times. This draft
>   paper on Reconfigurable I/O [1] has a C interface that I'm adapting at the
>   moment for use in Mirage. Balraj and Haris have also done extensive work
>   on TCP/OpenFlow, so we have a reasonably stable base now at least!
> 
> - Profiling and characterising *why* something is slow under Xen is
>   rather difficult currently, but should be easy to fix by implementing the
>   gprof stubs in our microkernel, and adjusting the build system. 
> 
> - Several of the libraries should be able to be used independently of
>   Mirage, most notably the xenstore implementation. Dave has pulled the
>   code out (github/djs55/ocaml-xenstore), and I'm going to fix the Mirage
>   build to use a git remote subrepo.  Ideally,  we should have a skeleton
>   library repository that can compile for normal UNIX Lwt as well as
>   Mirage.  This is only practical for libraries which dont interact much
>   with the system, but it's better than the current c&p situation.
> 
> - The most existing thing left to integrate is FRP-style I/O [2]. This
>   makes all kernel structures bidirectional. For example, rather than just
>   having an ARP cache, anything that queries the cache will be 'tied' to
>   it, and subsequent updates (e.g. an ARP packet or timeout) will result
>   in a recomputation of the upstream flow.  This is the essence of cloud
>   programming, where there are lots of environmental changes (e.g. live
>   relocation), and a Mirage kernel which handles them explicitly is an
>   interesting experiment.
> 
> So what this means is that the repository is going to undergo some short-term 
> volatility through January :)  I'll likely unhook most of the high-level 
> protocol libraries from the build, and make the benchmark library work with 
> Openflow/Ethernet first, and then up to TCP. Once we are happy that we can 
> profile and stress test those layers, I'll bring the DNS/HTTP/etc libraries 
> back in the new world.
> 
> However, all this work will happen in a branch, so you can continue to mess 
> around in the master branch to get a feel for the system.
> 
> [1] http://anil.recoil.org/papers/drafts/2012-resolve-draft1.pdf
> [2] http://ambassadortothecomputers.blogspot.com/2010/05/how-froc-works.html
> 
> > What is the status of/plans for the orm stuff?
> > (https://github.com/mirage/orm - seems to be outside the current 
> > 'release' and tutorial scope) (plan A for learning mirage was to try 
> > making a web application or two)
> 
> The ORM was a bit of an early experiment. It certainly works, but the 
> semantics of deletion are rather tricky. It's going to be a few months before 
> it can be hooked back in. However, the easiest way to build a small web app 
> is to compile in the data into the binary directly.
> 
> > Can I check my understanding on some of the networking stuff...
> > 
> > -          the unix-socket version uses sockets directly and doesn't try
> > to support the Ethif interface, whereas the unix-direct version does; 
> > this is the common low level interface (on both Xen and Unix) on which 
> > the ocaml ip stack is implemented (common to both targets)?
> 
> Yup.
> 
> > 
> > -          The Flow and esp. Channel and Manager interfaces are common
> > abstractions across all platforms? I have to say I am pretty unclear 
> > exactly what the role and function of the Manager is; I guess there is 
> > one per application, even if multiple interfaces, and there is some 
> > reference to "swap to shared memory" but this seems to be a promissory
> > note)
> 
> The Manager was intended to be the system wide service (so yes, it could 
> select libvchan sharedmem instead of TCP). However, that whole interface is 
> going to change into a higher-level 'open a URI flow' instead. You would just 
> open 'tcp://foo.bar:500' or 'xio://proc3' (for Mirage-internal calls). For 
> now, just use the Manager from the examples but don't get too attached to it 
> :)
> 
> > Can someone comment on the wisdom of using the unix socket vs direct 
> > version? (thinking of performance as well as stability)
> 
> Sockets are there to make developing the higher level protocols easier, 
> without worrying about TCP bugs.
> 
> > Is anyone working on the Node (or browser) version of the networking?
> > (which appears to just be an unimplemented shell)
> 
> Not really at the moment. It's a cool hack that keeps the architecture 
> 'honest' (i.e. no C bindings), but doesn't really have a compelling purpose 
> beyond that. Raphael did the most recent work, but it probably needs another 
> week or so to fix up the I/O bindings to node.js (which uses a Buffer 
> abstraction instead of Javascript strings)
> 
> > 
> > Some of the mirage build was broken (for me on Centos 6, anyway) by 
> > the recent change to some of the .sh file headers (e.g. assemble.sh) 
> > from #!/bin/bash to #!/usr/bin/env bash -e: /usr/bin/env: bash -e: No 
> > such file or directory
> > 
> > When I run any of the net examples as unix-direct (again on Centos 6), 
> > (having created tap0 explicitly using tunctl, which wasn't mentioned 
> > in the tutorial), it appears (from what it prints and from subsequent 
> > ifconfig output) to execute each time: /sbin/ifconfig tap0 10.0.0.2 
> > netmask 255.255.255.0 up But the mirage process is itself using ip 
> > 10.0.0.2, so I have to change the host interface ip back to 10.0.0.1
> > (e.g.) before I can communicate with the mirage process on ip 10.0.0.2
> 
> Ah, these might be due to Haris' hacks to get OpenFlow to work. I'm paging 
> back in to Mirage hacking now, so will tidy this stuff up too. 
> 
> -a
> 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