Re: deconstructing OS

[Anil Madhavapeddy <anil@xxxxxxxxxx>]

I've now split up the console code into 
https://github.com/mirage/mirage-console

which brings us to the next integration task.  The Unix code is obviously quite 
easy to build, but the Xen one requires Gnttab and Eventchn.  

Dave, Jon, there seem to be several of these floating around.  Do you have a 
Gnttab/Eventchn that is suitable to be structured as the Console/Clock and have 
a unix/xen directory with a module type defined?

I can pull one together that's just Xen for now, but thought I would check the 
state of the rest.

-anil

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

> 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
> 
>