Hosting the Pharo VM on MirageOS

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
21 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: Hosting the Pharo VM on MirageOS

NorbertHartl



Am 16.01.2015 um 00:50 schrieb Ben Coman <[hidden email]>:

Actually, the requirements to modify/link the vm make it more a [vm-dev] topic, but still interesting for [pharo-dev]s. 
It wouldn't be [pharo-users] until there was something to "use" :)

But you could use it if it would be there. Having it on pharo-users could lead to a lot of people showing their interest in using it. And it definetely is a use case :)

Norbert
On Fri, Jan 16, 2015 at 5:18 AM, Alain Rastoul <[hidden email]> wrote:
Le 15/01/2015 20:58, Joerg Beekmann, DeepCove Labs a écrit :




-----Original Message-----
From: Pharo-dev [mailto:[hidden email]] On Behalf
Of Alain Rastoul
Sent: Wednesday, January 14, 2015 10:39 PM
To: [hidden email]
Subject: Re: [Pharo-dev] Hosting the Pharo VM on MirageOS

Le 15/01/2015 03:08, Joerg Beekmann, DeepCove Labs a écrit :

I was not planning specializing the VM for the image. But rather
link in a VM with everything needed to run a range of images. The
dependencies are handled by creating an OCAML module that expresses
these and the VM code then lives in the module. The OCAML dependence
analyser (a sat solver) then ensures those are satisfied.

But if you don't have a specialized smalltalk vm and image, you will
have to embed full system dependencies, in order to build a full
working smalltalk system (having most part not working could be a
very bad thing), and then you loose the unikernel approach benefits
(very lean dedicated system, small attack surface etc.).
My implicit assumption was that these VM would be designed for running
headless web-services on smaller EC2 instances. And perhaps naively was
thinking that the number of system dependencies would be quite low:

- memory
- CPU
- networking stack
- http/https

- no file system but access to block storage (or perhaps even link
image in so no storage at all)
- mirage is single threaded with green threads so no
multithreading/processing

Honestly, the VM is not that large. There are not many variation points on that
level.
Where you want specialization is the *image*.

Thanks Marcus - good to know


        Marcus



Yes, the vm is not so big, and specialization has to be done in the image.
But there is a key point to mention about openmirage : if it started as unix (or linux, don't know), it is not linux at all as I understand it See chapter 3
http://queue.acm.org/detail.cfm?id=2566628
" ... The last compilation strategy drops the dependency on Unix entirely and recompiles the MirNet module to link directly to a Xen network driver, which in turn pulls in all the dependencies it needs to boot on Xen. This progressive recompilation is key to the usability of MirageOS, ... etc"

The compilation process produce a single compiled unit that includes your application linked with the needed libraries, ie: the kernel+application, there is no linux kernel and no processes at all.
Even driver's code is linked to you application.
It can be booted in a Xen guest vm like PharoNOS, Linux tiny core
or others linux but ...
I see a completely different animal is here :)
if I'm wrong, please correct me

NB: Is this thread about pharo devel ?
or should it be moved to pharo-users ?

--
Regards,

Alain



12