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
|

Hosting the Pharo VM on MirageOS

Joerg Beekmann, DeepCove Labs (YVR)
Hi

I've been exploring the possibility of hosting the Squeak/Pharo VM on MirageOS. MirageOS is a Unikernal or  "Library OS" where rather than creating an executable to be run on Linux the compiler analyses dependencies right down through the device drivers and creates a kernel that can be booted on Amazon AWS EC2.
    http://www.openmirage.org/
    http://queue.acm.org/detail.cfm?id=2566628
    http://blog.acolyer.org/2015/01/13/unikernels-library-operating-systems-for-the-cloud/

It seems to me that having a Smalltalk hosed in this environment would be quite useful on a number of fronts:
* A simple build and deploy of Smalltalk to the cloud. The Mirage group is building unikernals from sources and then because they are small committing the entire kernel to GitHub and then pushing the kernel to AWS EC2. Web sites and APIs are an obvious application.  http://amirchaudhry.com/from-jekyll-to-unikernel-in-fifty-lines/.
* Smalltalk on small devices. The Mirage group is running Xen with mirage on small Intel and ARM boards. See http://openmirage.org/blog/announcing-mirage-20-release/.
* These kernels can be very small, on the order of 0.25Meg for minimal HTTP servers with boot times in the ms range. A project called Jitsu https://github.com/MagnusS/jitsu modifies a DNS server to boot kernels in response to socket requests. The system making the request is unaware of the boot.
* The Mirage group envisions thousands of kernels running on a single Hypervisor with his speed inter-kernel communications. See http://openmirage.org/blog/update-on-vchan. The facilitates Smalltalk systems consisting of a swarm of communicating images where each image is single threaded and concurrency is via message passing.

I've corresponded with the MirageOS group asking if they thought a language VM could be hosted on Mirage. The discussion is here: http://lists.xenproject.org/archives/html/mirageos-devel/2015-01/msg00053.html. Assuming we understood each other it seems the answer is "yes that should be possible".

My question is what would be involved on the Smalltalk side? I presume the effort is going to be mostly in the VM. Based on the conversation on the Mirage list I think the VM will need to be able to run a Library with an entry point called by Mirage. That seems similar to the " Embedding/VM as a DLL" project proposed here: http://www.mirandabanda.org/cogblog/cog-projects/. Is this project active? The comment indicates this is mostly refactoring & repackaging. Anyone have a perspective on this?

Best regards

Joerg




Reply | Threaded
Open this post in threaded view
|

Re: Hosting the Pharo VM on MirageOS

Alain Rastoul-2
Le 14/01/2015 04:39, Joerg Beekmann, DeepCove Labs a écrit :

> Hi
>
> I've been exploring the possibility of hosting the Squeak/Pharo VM on MirageOS. MirageOS is a Unikernal or  "Library OS" where rather than creating an executable to be run on Linux the compiler analyses dependencies right down through the device drivers and creates a kernel that can be booted on Amazon AWS EC2.
>      http://www.openmirage.org/
>      http://queue.acm.org/detail.cfm?id=2566628
>      http://blog.acolyer.org/2015/01/13/unikernels-library-operating-systems-for-the-cloud/
>
> It seems to me that having a Smalltalk hosed in this environment would be quite useful on a number of fronts:
> * A simple build and deploy of Smalltalk to the cloud. The Mirage group is building unikernals from sources and then because they are small committing the entire kernel to GitHub and then pushing the kernel to AWS EC2. Web sites and APIs are an obvious application.  http://amirchaudhry.com/from-jekyll-to-unikernel-in-fifty-lines/.
> * Smalltalk on small devices. The Mirage group is running Xen with mirage on small Intel and ARM boards. See http://openmirage.org/blog/announcing-mirage-20-release/.
> * These kernels can be very small, on the order of 0.25Meg for minimal HTTP servers with boot times in the ms range. A project called Jitsu https://github.com/MagnusS/jitsu modifies a DNS server to boot kernels in response to socket requests. The system making the request is unaware of the boot.
> * The Mirage group envisions thousands of kernels running on a single Hypervisor with his speed inter-kernel communications. See http://openmirage.org/blog/update-on-vchan. The facilitates Smalltalk systems consisting of a swarm of communicating images where each image is single threaded and concurrency is via message passing.
>
> I've corresponded with the MirageOS group asking if they thought a language VM could be hosted on Mirage. The discussion is here: http://lists.xenproject.org/archives/html/mirageos-devel/2015-01/msg00053.html. Assuming we understood each other it seems the answer is "yes that should be possible".
>
> My question is what would be involved on the Smalltalk side? I presume the effort is going to be mostly in the VM. Based on the conversation on the Mirage list I think the VM will need to be able to run a Library with an entry point called by Mirage. That seems similar to the " Embedding/VM as a DLL" project proposed here: http://www.mirandabanda.org/cogblog/cog-projects/. Is this project active? The comment indicates this is mostly refactoring & repackaging. Anyone have a perspective on this?
>
> Best regards
>
> Joerg
>
>
>
>
>

Hi,

I've been thinking on that kind of question from a different point of
view: cutting an application
in parts, and running several single core pharo vm in different xen vms
with inter domain communication
(or network communication if clustered on different hosts) in order to
achieve multi core processing.
For ipc communication, I found libvchan , whose documentation seems to
be only the xen source code and a small sample in the code, and
the vicent bernadoff open mirage post (no a lot of doc)
and I also found  xen sockect, an older paper here
http://www.researchgate.net/publication/221461399_XenSocket_A_High-Throughput_Interdomain_Transport_for_Virtual_Machine/links/00b7d51cb10ec74e9b000000.pdf
that look interesting because it has the same api as sockets, but no
more information, it seems to be only an old research paper.
Forthe last one, it  has been be done on top of grant table and could
probably be written  but I guess not trivial at all.

About openmirage, since the unikernel has to deal with code dependencies,
how to integrate the dependency analyser with smalltalk code in order to
build a specialized vm ?
And about your idea of running the vm in a dll, how will it manage
primitives in specialized libraries ?
I suppose you would also have to go into the dependency toolchain to
describe pharo packages dependencies in terms of openmirage
functionality dependencies ?

May be you could also look at Android port of pharo, since it runs the
vm as a jni dll ?
But the primitive part of android port (libraries) do not have to deal
with dependencies since android is based on linux.

--
Regards,

Alain


Reply | Threaded
Open this post in threaded view
|

Re: Hosting the Pharo VM on MirageOS

Ben Coman
In reply to this post by Joerg Beekmann, DeepCove Labs (YVR)

On Wed, Jan 14, 2015 at 11:39 AM, Joerg Beekmann, DeepCove Labs <[hidden email]> wrote:
Hi

I've been exploring the possibility of hosting the Squeak/Pharo VM on MirageOS. MirageOS is a Unikernal or  "Library OS" where rather than creating an executable to be run on Linux the compiler analyses dependencies right down through the device drivers and creates a kernel that can be booted on Amazon AWS EC2.
    http://www.openmirage.org/
    http://queue.acm.org/detail.cfm?id=2566628
    http://blog.acolyer.org/2015/01/13/unikernels-library-operating-systems-for-the-cloud/

It seems to me that having a Smalltalk hosed in this environment would be quite useful on a number of fronts:
* A simple build and deploy of Smalltalk to the cloud. The Mirage group is building unikernals from sources and then because they are small committing the entire kernel to GitHub and then pushing the kernel to AWS EC2. Web sites and APIs are an obvious application.  http://amirchaudhry.com/from-jekyll-to-unikernel-in-fifty-lines/.
* Smalltalk on small devices. The Mirage group is running Xen with mirage on small Intel and ARM boards. See http://openmirage.org/blog/announcing-mirage-20-release/.
* These kernels can be very small, on the order of 0.25Meg for minimal HTTP servers with boot times in the ms range. A project called Jitsu https://github.com/MagnusS/jitsu modifies a DNS server to boot kernels in response to socket requests. The system making the request is unaware of the boot.
* The Mirage group envisions thousands of kernels running on a single Hypervisor with his speed inter-kernel communications. See http://openmirage.org/blog/update-on-vchan. The facilitates Smalltalk systems consisting of a swarm of communicating images where each image is single threaded and concurrency is via message passing.

I've corresponded with the MirageOS group asking if they thought a language VM could be hosted on Mirage. The discussion is here: http://lists.xenproject.org/archives/html/mirageos-devel/2015-01/msg00053.html. Assuming we understood each other it seems the answer is "yes that should be possible".

My question is what would be involved on the Smalltalk side? I presume the effort is going to be mostly in the VM. Based on the conversation on the Mirage list I think the VM will need to be able to run a Library with an entry point called by Mirage. That seems similar to the " Embedding/VM as a DLL" project proposed here: http://www.mirandabanda.org/cogblog/cog-projects/. Is this project active? The comment indicates this is mostly refactoring & repackaging. Anyone have a perspective on this?

Best regards

Joerg



Mirarge might be a good stepping stone, but ultimately I think we want Cog running directly on the Xen "hardware" without Mirage.  Erlang and Haskell are languages that already do this. [1]  We need to get on that list at the bottom.  

Maybe a good starting place is SqueakNOS [2] since it is reported to work with Grub and there is PVGrub [3] [4]. 

btw,  Did you see the discussion titled "Cog In The Cloud"
and a little bit extra at the bottom of this one...


Reply | Threaded
Open this post in threaded view
|

Re: Hosting the Pharo VM on MirageOS

EstebanLM

On 14 Jan 2015, at 08:15, Ben Coman <[hidden email]> wrote:


On Wed, Jan 14, 2015 at 11:39 AM, Joerg Beekmann, DeepCove Labs <[hidden email]> wrote:
Hi

I've been exploring the possibility of hosting the Squeak/Pharo VM on MirageOS. MirageOS is a Unikernal or  "Library OS" where rather than creating an executable to be run on Linux the compiler analyses dependencies right down through the device drivers and creates a kernel that can be booted on Amazon AWS EC2.
    http://www.openmirage.org/
    http://queue.acm.org/detail.cfm?id=2566628
    http://blog.acolyer.org/2015/01/13/unikernels-library-operating-systems-for-the-cloud/

It seems to me that having a Smalltalk hosed in this environment would be quite useful on a number of fronts:
* A simple build and deploy of Smalltalk to the cloud. The Mirage group is building unikernals from sources and then because they are small committing the entire kernel to GitHub and then pushing the kernel to AWS EC2. Web sites and APIs are an obvious application.  http://amirchaudhry.com/from-jekyll-to-unikernel-in-fifty-lines/.
* Smalltalk on small devices. The Mirage group is running Xen with mirage on small Intel and ARM boards. See http://openmirage.org/blog/announcing-mirage-20-release/.
* These kernels can be very small, on the order of 0.25Meg for minimal HTTP servers with boot times in the ms range. A project called Jitsu https://github.com/MagnusS/jitsu modifies a DNS server to boot kernels in response to socket requests. The system making the request is unaware of the boot.
* The Mirage group envisions thousands of kernels running on a single Hypervisor with his speed inter-kernel communications. See http://openmirage.org/blog/update-on-vchan. The facilitates Smalltalk systems consisting of a swarm of communicating images where each image is single threaded and concurrency is via message passing.

I've corresponded with the MirageOS group asking if they thought a language VM could be hosted on Mirage. The discussion is here: http://lists.xenproject.org/archives/html/mirageos-devel/2015-01/msg00053.html. Assuming we understood each other it seems the answer is "yes that should be possible".

My question is what would be involved on the Smalltalk side? I presume the effort is going to be mostly in the VM. Based on the conversation on the Mirage list I think the VM will need to be able to run a Library with an entry point called by Mirage. That seems similar to the " Embedding/VM as a DLL" project proposed here: http://www.mirandabanda.org/cogblog/cog-projects/. Is this project active? The comment indicates this is mostly refactoring & repackaging. Anyone have a perspective on this?

Best regards

Joerg



Mirarge might be a good stepping stone, but ultimately I think we want Cog running directly on the Xen "hardware" without Mirage.  Erlang and Haskell are languages that already do this. [1]  We need to get on that list at the bottom.  

Maybe a good starting place is SqueakNOS [2] since it is reported to work with Grub and there is PVGrub [3] [4]. 

or PharoNOS :)




Reply | Threaded
Open this post in threaded view
|

Re: Hosting the Pharo VM on MirageOS

Marcus Denker-4


Mirarge might be a good stepping stone, but ultimately I think we want Cog running directly on the Xen "hardware" without Mirage.  Erlang and Haskell are languages that already do this. [1]  We need to get on that list at the bottom.  

Maybe a good starting place is SqueakNOS [2] since it is reported to work with Grub and there is PVGrub [3] [4]. 

or PharoNOS :)


But this one actually has a small Linux as the base… so it is not “NOS” in this sense.

Marcus

Reply | Threaded
Open this post in threaded view
|

Re: Hosting the Pharo VM on MirageOS

ccrraaiigg
In reply to this post by Joerg Beekmann, DeepCove Labs (YVR)

Hoi Joerg--

> The Mirage group envisions thousands of kernels running on a single
> Hypervisor with his speed inter-kernel communications. See
> http://openmirage.org/blog/update-on-vchan. The facilitates Smalltalk
> systems consisting of a swarm of communicating images where each
> image is single threaded and concurrency is via message passing.

     Cool! This would be a good place to use Context[1,2].


-C

[1] https://github.com/ccrraaiigg/context
[2] http://thiscontext.com

--
Craig Latta
netjam.org
+31   6 2757 7177 (SMS ok)
+ 1 415  287 3547 (no SMS)


Reply | Threaded
Open this post in threaded view
|

Re: Hosting the Pharo VM on MirageOS

Eliot Miranda-2
In reply to this post by Ben Coman


On Wed, Jan 14, 2015 at 3:15 AM, Ben Coman <[hidden email]> wrote:

On Wed, Jan 14, 2015 at 11:39 AM, Joerg Beekmann, DeepCove Labs <[hidden email]> wrote:
Hi

I've been exploring the possibility of hosting the Squeak/Pharo VM on MirageOS. MirageOS is a Unikernal or  "Library OS" where rather than creating an executable to be run on Linux the compiler analyses dependencies right down through the device drivers and creates a kernel that can be booted on Amazon AWS EC2.
    http://www.openmirage.org/
    http://queue.acm.org/detail.cfm?id=2566628
    http://blog.acolyer.org/2015/01/13/unikernels-library-operating-systems-for-the-cloud/

It seems to me that having a Smalltalk hosed in this environment would be quite useful on a number of fronts:
* A simple build and deploy of Smalltalk to the cloud. The Mirage group is building unikernals from sources and then because they are small committing the entire kernel to GitHub and then pushing the kernel to AWS EC2. Web sites and APIs are an obvious application.  http://amirchaudhry.com/from-jekyll-to-unikernel-in-fifty-lines/.
* Smalltalk on small devices. The Mirage group is running Xen with mirage on small Intel and ARM boards. See http://openmirage.org/blog/announcing-mirage-20-release/.
* These kernels can be very small, on the order of 0.25Meg for minimal HTTP servers with boot times in the ms range. A project called Jitsu https://github.com/MagnusS/jitsu modifies a DNS server to boot kernels in response to socket requests. The system making the request is unaware of the boot.
* The Mirage group envisions thousands of kernels running on a single Hypervisor with his speed inter-kernel communications. See http://openmirage.org/blog/update-on-vchan. The facilitates Smalltalk systems consisting of a swarm of communicating images where each image is single threaded and concurrency is via message passing.

I've corresponded with the MirageOS group asking if they thought a language VM could be hosted on Mirage. The discussion is here: http://lists.xenproject.org/archives/html/mirageos-devel/2015-01/msg00053.html. Assuming we understood each other it seems the answer is "yes that should be possible".

My question is what would be involved on the Smalltalk side? I presume the effort is going to be mostly in the VM. Based on the conversation on the Mirage list I think the VM will need to be able to run a Library with an entry point called by Mirage. That seems similar to the " Embedding/VM as a DLL" project proposed here: http://www.mirandabanda.org/cogblog/cog-projects/. Is this project active? The comment indicates this is mostly refactoring & repackaging. Anyone have a perspective on this?

Best regards

Joerg



Mirarge might be a good stepping stone, but ultimately I think we want Cog running directly on the Xen "hardware" without Mirage.  Erlang and Haskell are languages that already do this. [1]  We need to get on that list at the bottom.  

+1.  I am trying to get funding to do this, including modifying the execution model to provide excellent debugging facilities for promise-style concurrency (adding scheme-like continuation support to the VM, and allowing exception search to proceed from a promise to its creating context, etc).

Maybe a good starting place is SqueakNOS [2] since it is reported to work with Grub and there is PVGrub [3] [4]. 

I'm not sure.  Xen has a special segmented memory model so assuming, as the existing VMs do, a single contiguous heap is not a good match.  Spur on the other hand has good support for memory segmentation.  Further, one wants a high-performance VM, and Sista provides adaptive optimization potentially with no warmup time because one can save an optimized image).  

I should say that starting in February I am changing to half-time at Cadence.  Half of my time is therefore available for me to bootstrap a business around Pharo, Squeak and the Cog, Spur and Sista VMs.  If this is successful I hope to become independent full-time, or rather that I'm in a Snalltalk-centric company if which I'm a co-founder.  I'm working with specific people in the community and one thing we imagine is a company with close ties to Rmod.  It would be vry nice to grow a company where people completing their PhDs at Rmod had somewhere to go where they could continue working with Pharo instead of going to Google et al.  There us a clear need for companies around Pharo that can contract to provide technology services. Such a thing will take a while to ramp up, but the time is ripe.



--
best,
Eliot
Reply | Threaded
Open this post in threaded view
|

Re: Hosting the Pharo VM on MirageOS

Alain Rastoul-2

Le 14/01/2015 21:12, Eliot Miranda a écrit :

>
>
> On Wed, Jan 14, 2015 at 3:15 AM, Ben Coman
> <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>
>     On Wed, Jan 14, 2015 at 11:39 AM, Joerg Beekmann, DeepCove Labs
>     <[hidden email]
>     <mailto:[hidden email]>> wrote:
>
>         Hi
>
>         I've been exploring the possibility of hosting the Squeak/Pharo
>         VM on MirageOS. MirageOS is a Unikernal or  "Library OS" where
>         rather than creating an executable to be run on Linux the
>         compiler analyses dependencies right down through the device
>         drivers and creates a kernel that can be booted on Amazon AWS EC2.
>         http://www.openmirage.org/
>         http://queue.acm.org/detail.cfm?id=2566628
>         http://blog.acolyer.org/2015/01/13/unikernels-library-operating-systems-for-the-cloud/
>
>         It seems to me that having a Smalltalk hosed in this environment
>         would be quite useful on a number of fronts:
>         * A simple build and deploy of Smalltalk to the cloud. The
>         Mirage group is building unikernals from sources and then
>         because they are small committing the entire kernel to GitHub
>         and then pushing the kernel to AWS EC2. Web sites and APIs are
>         an obvious application.
>         http://amirchaudhry.com/from-jekyll-to-unikernel-in-fifty-lines/.
>         * Smalltalk on small devices. The Mirage group is running Xen
>         with mirage on small Intel and ARM boards. See
>         http://openmirage.org/blog/announcing-mirage-20-release/.
>         * These kernels can be very small, on the order of 0.25Meg for
>         minimal HTTP servers with boot times in the ms range. A project
>         called Jitsu https://github.com/MagnusS/jitsu modifies a DNS
>         server to boot kernels in response to socket requests. The
>         system making the request is unaware of the boot.
>         * The Mirage group envisions thousands of kernels running on a
>         single Hypervisor with his speed inter-kernel communications.
>         See http://openmirage.org/blog/update-on-vchan. The facilitates
>         Smalltalk systems consisting of a swarm of communicating images
>         where each image is single threaded and concurrency is via
>         message passing.
>
>         I've corresponded with the MirageOS group asking if they thought
>         a language VM could be hosted on Mirage. The discussion is here:
>         http://lists.xenproject.org/archives/html/mirageos-devel/2015-01/msg00053.html.
>         Assuming we understood each other it seems the answer is "yes
>         that should be possible".
>
>         My question is what would be involved on the Smalltalk side? I
>         presume the effort is going to be mostly in the VM. Based on the
>         conversation on the Mirage list I think the VM will need to be
>         able to run a Library with an entry point called by Mirage. That
>         seems similar to the " Embedding/VM as a DLL" project proposed
>         here: http://www.mirandabanda.org/cogblog/cog-projects/. Is this
>         project active? The comment indicates this is mostly refactoring
>         & repackaging. Anyone have a perspective on this?
>
>         Best regards
>
>         Joerg
>
>
>
>     Mirarge might be a good stepping stone, but ultimately I think we
>     want Cog running directly on the Xen "hardware" without Mirage.
>     Erlang and Haskell are languages that already do this. [1]  We need
>     to get on that list at the bottom.
>
>
> +1.  I am trying to get funding to do this, including modifying the
> execution model to provide excellent debugging facilities for
> promise-style concurrency (adding scheme-like continuation support to
> the VM, and allowing exception search to proceed from a promise to its
> creating context, etc).
>
>     Maybe a good starting place is SqueakNOS [2] since it is reported to
>     work with Grub and there is PVGrub [3] [4].
>
>
> I'm not sure. Xen has a special segmented memory model so assuming, as
> the existing VMs do, a single contiguous heap is not a good match.  Spur
> on the other hand has good support for memory segmentation. Further, one
> wants a high-performance VM, and Sista provides adaptive optimization
> potentially with no warmup time because one can save an optimized image).
>
> I should say that starting in February I am changing to half-time at
> Cadence.  Half of my time is therefore available for me to bootstrap a
> business around Pharo, Squeak and the Cog, Spur and Sista VMs.  If this
> is successful I hope to become independent full-time, or rather that I'm
> in a Snalltalk-centric company if which I'm a co-founder.  I'm working
> with specific people in the community and one thing we imagine is a
> company with close ties to Rmod.  It would be vry nice to grow a company
> where people completing their PhDs at Rmod had somewhere to go where
> they could continue working with Pharo instead of going to Google et al.
>   There us a clear need for companies around Pharo that can contract to
> provide technology services. Such a thing will take a while to ramp up,
> but the time is ripe.
>
Those are really great news!
For the Pharo system and for smalltalk too I think.
Virtualization is the way to go for now,
and it should perfectly fit with Pharo smalltalk
(nice to hear that next vms will match too).

I wish you success in your enterprise



--
Regards,

Alain


Reply | Threaded
Open this post in threaded view
|

Re: Hosting the Pharo VM on MirageOS

stepharo
In reply to this post by Joerg Beekmann, DeepCove Labs (YVR)
Yes we would love that too!!!

> Hi
>
> I've been exploring the possibility of hosting the Squeak/Pharo VM on MirageOS. MirageOS is a Unikernal or  "Library OS" where rather than creating an executable to be run on Linux the compiler analyses dependencies right down through the device drivers and creates a kernel that can be booted on Amazon AWS EC2.
>      http://www.openmirage.org/
>      http://queue.acm.org/detail.cfm?id=2566628
>      http://blog.acolyer.org/2015/01/13/unikernels-library-operating-systems-for-the-cloud/
>
> It seems to me that having a Smalltalk hosed in this environment would be quite useful on a number of fronts:
> * A simple build and deploy of Smalltalk to the cloud. The Mirage group is building unikernals from sources and then because they are small committing the entire kernel to GitHub and then pushing the kernel to AWS EC2. Web sites and APIs are an obvious application.  http://amirchaudhry.com/from-jekyll-to-unikernel-in-fifty-lines/.
> * Smalltalk on small devices. The Mirage group is running Xen with mirage on small Intel and ARM boards. See http://openmirage.org/blog/announcing-mirage-20-release/.
> * These kernels can be very small, on the order of 0.25Meg for minimal HTTP servers with boot times in the ms range. A project called Jitsu https://github.com/MagnusS/jitsu modifies a DNS server to boot kernels in response to socket requests. The system making the request is unaware of the boot.
> * The Mirage group envisions thousands of kernels running on a single Hypervisor with his speed inter-kernel communications. See http://openmirage.org/blog/update-on-vchan. The facilitates Smalltalk systems consisting of a swarm of communicating images where each image is single threaded and concurrency is via message passing.
>
> I've corresponded with the MirageOS group asking if they thought a language VM could be hosted on Mirage. The discussion is here: http://lists.xenproject.org/archives/html/mirageos-devel/2015-01/msg00053.html. Assuming we understood each other it seems the answer is "yes that should be possible".
>
> My question is what would be involved on the Smalltalk side? I presume the effort is going to be mostly in the VM. Based on the conversation on the Mirage list I think the VM will need to be able to run a Library with an entry point called by Mirage. That seems similar to the " Embedding/VM as a DLL" project proposed here: http://www.mirandabanda.org/cogblog/cog-projects/. Is this project active? The comment indicates this is mostly refactoring & repackaging. Anyone have a perspective on this?
>
> Best regards
>
> Joerg
>
>
>
>
>


Reply | Threaded
Open this post in threaded view
|

Re: Hosting the Pharo VM on MirageOS

Joerg Beekmann, DeepCove Labs (YVR)
In reply to this post by Alain Rastoul-2


> -----Original Message-----
> From: Pharo-dev [mailto:[hidden email]] On Behalf Of
> Alain Rastoul
> Sent: Tuesday, January 13, 2015 11:10 PM
> To: [hidden email]
> Subject: Re: [Pharo-dev] Hosting the Pharo VM on MirageOS
>
> Le 14/01/2015 04:39, Joerg Beekmann, DeepCove Labs a écrit :
> > Hi
> >
> > I've been exploring the possibility of hosting the Squeak/Pharo VM on
> MirageOS. MirageOS is a Unikernal or  "Library OS" where rather than creating
> an executable to be run on Linux the compiler analyses dependencies right
> down through the device drivers and creates a kernel that can be booted on
> Amazon AWS EC2.
> >      http://www.openmirage.org/
> >      http://queue.acm.org/detail.cfm?id=2566628
> >
> > http://blog.acolyer.org/2015/01/13/unikernels-library-operating-system
> > s-for-the-cloud/
> >
> > It seems to me that having a Smalltalk hosed in this environment would be
> quite useful on a number of fronts:
> > * A simple build and deploy of Smalltalk to the cloud. The Mirage group is
> building unikernals from sources and then because they are small committing
> the entire kernel to GitHub and then pushing the kernel to AWS EC2. Web sites
> and APIs are an obvious application.  http://amirchaudhry.com/from-jekyll-to-
> unikernel-in-fifty-lines/.
> > * Smalltalk on small devices. The Mirage group is running Xen with mirage on
> small Intel and ARM boards. See http://openmirage.org/blog/announcing-
> mirage-20-release/.
> > * These kernels can be very small, on the order of 0.25Meg for minimal HTTP
> servers with boot times in the ms range. A project called Jitsu
> https://github.com/MagnusS/jitsu modifies a DNS server to boot kernels in
> response to socket requests. The system making the request is unaware of the
> boot.
> > * The Mirage group envisions thousands of kernels running on a single
> Hypervisor with his speed inter-kernel communications. See
> http://openmirage.org/blog/update-on-vchan. The facilitates Smalltalk systems
> consisting of a swarm of communicating images where each image is single
> threaded and concurrency is via message passing.
> >
> > I've corresponded with the MirageOS group asking if they thought a language
> VM could be hosted on Mirage. The discussion is here:
> http://lists.xenproject.org/archives/html/mirageos-devel/2015-
> 01/msg00053.html. Assuming we understood each other it seems the answer
> is "yes that should be possible".
> >
> > My question is what would be involved on the Smalltalk side? I presume the
> effort is going to be mostly in the VM. Based on the conversation on the Mirage
> list I think the VM will need to be able to run a Library with an entry point called
> by Mirage. That seems similar to the " Embedding/VM as a DLL" project
> proposed here: http://www.mirandabanda.org/cogblog/cog-projects/. Is this
> project active? The comment indicates this is mostly refactoring &
> repackaging. Anyone have a perspective on this?
> >
> > Best regards
> >
> > Joerg
> >
> >
> >
> >
> >
>
> Hi,
>
> I've been thinking on that kind of question from a different point of
> view: cutting an application
> in parts, and running several single core pharo vm in different xen vms with
> inter domain communication (or network communication if clustered on
> different hosts) in order to achieve multi core processing.
> For ipc communication, I found libvchan , whose documentation seems to be
> only the xen source code and a small sample in the code, and the vicent
> bernadoff open mirage post (no a lot of doc) and I also found  xen sockect, an
> older paper here
> http://www.researchgate.net/publication/221461399_XenSocket_A_High-
> Throughput_Interdomain_Transport_for_Virtual_Machine/links/00b7d51cb10e
> c74e9b000000.pdf
> that look interesting because it has the same api as sockets, but no more
> information, it seems to be only an old research paper.
> Forthe last one, it  has been be done on top of grant table and could probably be
> written  but I guess not trivial at all.

For an example of some work being done in this area by the mirage group see: http://openmirage.org/blog/update-on-vchan.
They seem to have come some way with this. Here is the bottom line. I've seen no sign of the next post.
    "vchan is a very low-level communication mechanism, and so our next post on this topic will address
    how to use it in combination with a name resolver to intelligently map connection requests to use vchan
     if available, and otherwise fall back to normal TCP or TCP+TLS."

> About openmirage, since the unikernel has to deal with code dependencies,
> how to integrate the dependency analyser with smalltalk code in order to build
> a specialized vm ?
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.

> And about your idea of running the vm in a dll, how will it manage primitives in
> specialized libraries ?
That I don't know. Probably pick a reasonable set of default primitives. I'll note the idea of the VM as a dll was not
mine but rather seemed to be a proposed project on Eliot's Cog Blog.

> I suppose you would also have to go into the dependency toolchain to describe
> pharo packages dependencies in terms of openmirage functionality
> dependencies ?
>
> May be you could also look at Android port of pharo, since it runs the vm as a jni
> dll ?
I will thanks!

> But the primitive part of android port (libraries) do not have to deal with
> dependencies since android is based on linux.
Mirage is also Linux in a sense. It You can run Mirage applications as user executable on Linux. That is how they are typically debugged. The cool idea is to then say
"lets perform whole system dependency analysis and build a Kernel with only what our application needs".
>
> --
> Regards,
>
> Alain
>
Hi Alain



Reply | Threaded
Open this post in threaded view
|

Re: Hosting the Pharo VM on MirageOS

Alain Rastoul-2
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.).

And yo uget a standard vm, call it NOS, NONOS or whatever :)

May be have a look at Spoon (suggested by Craig) and Seed and Hazelnut
http://rmod.inria.fr/web/software/Seed


--
Regards,

Alain


Reply | Threaded
Open this post in threaded view
|

Re: Hosting the Pharo VM on MirageOS

Alain Rastoul-2
Le 15/01/2015 07:38, Alain Rastoul a écrit :
>
> And yo uget a standard vm, call it NOS, NONOS or whatever :)
>
>
BTW thinking to that it could be still much lighter and more specialized
than most linux distros (no dameons, less libraries etc).
Expressing smalltalk libraries dependencies in the sat solver should be
possible.
I'll dig into the mirage discussion and links later, I'm interested too


--
Regards,

Alain


Reply | Threaded
Open this post in threaded view
|

Re: Hosting the Pharo VM on MirageOS

Joerg Beekmann, DeepCove Labs (YVR)
In reply to this post by Alain Rastoul-2


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

It may be possible to configure things on a per-image basis but I've not gotten that ambitious. The way to do this on the mirage side is to adjust the dependences stated in the module that wraps the VM. I don't know how the image could affect the code that goes into the VM. By modifying the VMMaker I suppose.


>
> And yo uget a standard vm, call it NOS, NONOS or whatever :)
>
> May be have a look at Spoon (suggested by Craig) and Seed and Hazelnut
> http://rmod.inria.fr/web/software/Seed
>
>
> --
> Regards,
>
> Alain
>


Reply | Threaded
Open this post in threaded view
|

Re: Hosting the Pharo VM on MirageOS

Marcus Denker-4

> On 15 Jan 2015, at 12:43, Joerg Beekmann, DeepCove Labs <[hidden email]> wrote:
>
>
>
>> -----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 specialisation is the *image*.

        Marcus
Reply | Threaded
Open this post in threaded view
|

Re: Hosting the Pharo VM on MirageOS

Sven Van Caekenberghe-2
In reply to this post by Joerg Beekmann, DeepCove Labs (YVR)

> On 15 Jan 2015, at 16:43, Joerg Beekmann, DeepCove Labs <[hidden email]> wrote:
>
> My implicit assumption was that these VM would be designed for running headless web-services on smaller EC2 instances.

Not that it would not be good to work out some of the ideas mentioned in this thread, but what you are mentioning above is perfectly possible today and is being done by many people on this list.

For web apps and web services, networking and persistent storage (some form of database) are the main bottlenecks.
Reply | Threaded
Open this post in threaded view
|

Re: Hosting the Pharo VM on MirageOS

Joerg Beekmann, DeepCove Labs (YVR)
In reply to this post by Marcus Denker-4


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


Reply | Threaded
Open this post in threaded view
|

Re: Hosting the Pharo VM on MirageOS

Alain Rastoul-2
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


Reply | Threaded
Open this post in threaded view
|

Re: Hosting the Pharo VM on MirageOS

Ben Coman
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" :)

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



Reply | Threaded
Open this post in threaded view
|

Re: Hosting the Pharo VM on MirageOS

Alain Rastoul-2
Le 16/01/2015 00:50, Ben Coman a écrit :
> Actually, the requirements to modify/link the vm make it more a [vm-dev]
> topic, but still interesting for [pharo-dev]s.

that's how I understand it, but the distinction is not allways clear:
standard frameworks devel (not use) who are part of the system should go
here too IMHO, but that's an opinion.

May be a private list for the pharo-devs would be better for them not to
be disturbed (that I can understand) , keeping the two lists open to
everybody: users for general and use of the system and devel for vm or
system related stuff. Or only one list open to every body and one private.
For now, I don't want to ask myself if people will be diturbed or not or
if they will answer or not, or to ask myself is it really pharodev or
pharo use ?
I think I will allways post questions on pharo-users, I will not disturb
anybody, no problem :)

> It wouldn't be [pharo-users] until there was something to "use" :)
>
> On Fri, Jan 16, 2015 at 5:18 AM, Alain Rastoul
> <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     Le 15/01/2015 20:58, Joerg Beekmann, DeepCove Labs a écrit :
>
>
>
>
>                     -----Original Message-----
>                     From: Pharo-dev
>                     [mailto:[hidden email]
>                     <mailto:[hidden email]>]
>                     On Behalf
>                     Of Alain Rastoul
>                     Sent: Wednesday, January 14, 2015 10:39 PM
>                     To: [hidden email]
>                     <mailto:[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
>     <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
>
>
>


--
Regards,

Alain


Reply | Threaded
Open this post in threaded view
|

Re: Hosting the Pharo VM on MirageOS

Alain Rastoul-2
In reply to this post by Joerg Beekmann, DeepCove Labs (YVR)
Le 14/01/2015 04:39, Joerg Beekmann, DeepCove Labs a écrit :

> Hi
>
> I've been exploring the possibility of hosting the Squeak/Pharo VM on MirageOS. MirageOS is a Unikernal or  "Library OS" where rather than creating an executable to be run on Linux the compiler analyses dependencies right down through the device drivers and creates a kernel that can be booted on Amazon AWS EC2.
>      http://www.openmirage.org/
>      http://queue.acm.org/detail.cfm?id=2566628
>      http://blog.acolyer.org/2015/01/13/unikernels-library-operating-systems-for-the-cloud/
>
> It seems to me that having a Smalltalk hosed in this environment would be quite useful on a number of fronts:
> * A simple build and deploy of Smalltalk to the cloud. The Mirage group is building unikernals from sources and then because they are small committing the entire kernel to GitHub and then pushing the kernel to AWS EC2. Web sites and APIs are an obvious application.  http://amirchaudhry.com/from-jekyll-to-unikernel-in-fifty-lines/.
> * Smalltalk on small devices. The Mirage group is running Xen with mirage on small Intel and ARM boards. See http://openmirage.org/blog/announcing-mirage-20-release/.
> * These kernels can be very small, on the order of 0.25Meg for minimal HTTP servers with boot times in the ms range. A project called Jitsu https://github.com/MagnusS/jitsu modifies a DNS server to boot kernels in response to socket requests. The system making the request is unaware of the boot.
> * The Mirage group envisions thousands of kernels running on a single Hypervisor with his speed inter-kernel communications. See http://openmirage.org/blog/update-on-vchan. The facilitates Smalltalk systems consisting of a swarm of communicating images where each image is single threaded and concurrency is via message passing.
>
> I've corresponded with the MirageOS group asking if they thought a language VM could be hosted on Mirage. The discussion is here: http://lists.xenproject.org/archives/html/mirageos-devel/2015-01/msg00053.html. Assuming we understood each other it seems the answer is "yes that should be possible".
>
> My question is what would be involved on the Smalltalk side? I presume the effort is going to be mostly in the VM. Based on the conversation on the Mirage list I think the VM will need to be able to run a Library with an entry point called by Mirage. That seems similar to the " Embedding/VM as a DLL" project proposed here: http://www.mirandabanda.org/cogblog/cog-projects/. Is this project active? The comment indicates this is mostly refactoring & repackaging. Anyone have a perspective on this?
>
> Best regards
>
> Joerg
>
>
>
>
>

Given that the openmirage kernel is written mostly in ocaml, I think
that the "port" of the vm could imply quite some work, like rewriting
the plugins (socket at first), dealing with Ocaml bindings etc. and not
easy at all.

Digging into that, I went across the rump kernel, and think that it may
be much simpler to deal with than openmirage, with some nice other
features (micro or dedicated kernels) that could make the pharo system a
pharo os.
see
http://rumpkernel.org/
and http://lib.tkk.fi/Diss/2012/isbn9789526049175/isbn9789526049175.pdf
It is still a unix kernel (NetBDS)
written in C so more friendly to lot of developers and much simpler for
pharo vm port
integrates well in xen and other hypervisors
can be run without the hypervisor platform
can be tailored at will, and give very lean systems.
Extremely interesting


--
Regards,

Alain


12