Re: deconstructing OS

[Anil Madhavapeddy <anil@xxxxxxxxxx>]

One important point I forgot to mention: moving these libraries like this will 
remove them from the packed OS namespace and out into the toplevel.

This will break code, but I plan to add a mirage-platform/<>/oS.ml that will 
include the toplevel modules, just as the Core(.Std) libraries do.  

-anil

On 7 Nov 2013, at 17:21, Anil Madhavapeddy <anil@xxxxxxxxxx> wrote:

> We've been slowly decomposing the OS module that's built by mirage-platform 
> into separate libraries for a while now, but I've taken the plunge and 
> created three experimental repositories for 0.9.9:
> 
> - mirage-types : https://github.com/mirage/mirage-types
> 
> This contains a single set of module types that build without any 
> dependencies.  Right now they contain just IO_PAGE and CLOCK. The intention 
> is that they can be satisfied by a specific implementation, so an application 
> can functorize over these to be really portable.  It puts them all under a V1 
> module to permit future enhancements.
> 
> - io-page : https://github.com/mirage/io-page
> 
> This is the standard io_page from mirage-platform, pulled into a separate 
> library.  The lib_test directory has a portability test that attempts to cast 
> the module into V1.IO_PAGE (and this did in fact find a missing function in 
> the Xen version vs the Unix version).
> 
> - mirage-clock : https://github.com/mirage/mirage-clock
> 
> Just the simple clock functions from mirage-platform, against cast against 
> V1.CLOCK
> 
> An important part of these libraries is that they can build independently of 
> Mirage-platform, so a normal UNIX app can just go ahead and use Io_page 
> without having to ever worry about Xen things.
> 
> Thoughts?  This split will leave very little in Mirage-platform (just the 
> Time and Main modules), along with the runtime libraries, but result in more 
> repositories.  I think OPAM mostly takes care of the latter problem however...
> 
> -anil