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-... 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.ht.... 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
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-...
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.ht.... 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-Throughpu... 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
-----Original Message----- From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On Behalf Of Alain Rastoul Sent: Tuesday, January 13, 2015 11:10 PM To: pharo-dev@lists.pharo.org 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
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
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
-----Original Message----- From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On Behalf Of Alain Rastoul Sent: Wednesday, January 14, 2015 10:39 PM To: pharo-dev@lists.pharo.org 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
On 15 Jan 2015, at 12:43, Joerg Beekmann, DeepCove Labs <joerg@deepcovelabs.com> wrote:
-----Original Message----- From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On Behalf Of Alain Rastoul Sent: Wednesday, January 14, 2015 10:39 PM To: pharo-dev@lists.pharo.org 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
-----Original Message----- From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On Behalf Of Alain Rastoul Sent: Wednesday, January 14, 2015 10:39 PM To: pharo-dev@lists.pharo.org 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
Le 15/01/2015 20:58, Joerg Beekmann, DeepCove Labs a écrit :
-----Original Message----- From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On Behalf Of Alain Rastoul Sent: Wednesday, January 14, 2015 10:39 PM To: pharo-dev@lists.pharo.org 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
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 <alf.mmm.cat@gmail.com> wrote:
Le 15/01/2015 20:58, Joerg Beekmann, DeepCove Labs a écrit :
-----Original Message-----
From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On Behalf Of Alain Rastoul Sent: Wednesday, January 14, 2015 10:39 PM To: pharo-dev@lists.pharo.org 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
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 <alf.mmm.cat@gmail.com <mailto:alf.mmm.cat@gmail.com>> wrote:
Le 15/01/2015 20:58, Joerg Beekmann, DeepCove Labs a écrit :
-----Original Message----- From: Pharo-dev [mailto:pharo-dev-bounces@__lists.pharo.org <mailto:pharo-dev-bounces@lists.pharo.org>] On Behalf Of Alain Rastoul Sent: Wednesday, January 14, 2015 10:39 PM To: pharo-dev@lists.pharo.org <mailto:pharo-dev@lists.pharo.org> 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
Am 16.01.2015 um 00:50 schrieb Ben Coman <btc@openInWorld.com>:
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 <alf.mmm.cat@gmail.com> wrote: Le 15/01/2015 20:58, Joerg Beekmann, DeepCove Labs a écrit :
-----Original Message----- From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On Behalf Of Alain Rastoul Sent: Wednesday, January 14, 2015 10:39 PM To: pharo-dev@lists.pharo.org 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
On 15 Jan 2015, at 16:43, Joerg Beekmann, DeepCove Labs <joerg@deepcovelabs.com> 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.
On Wed, Jan 14, 2015 at 11:39 AM, Joerg Beekmann, DeepCove Labs < joerg@deepcovelabs.com> 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-...
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.ht.... 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" http://forum.world.st/Cog-in-the-cloud-td4796515.html#a4796520 and a little bit extra at the bottom of this one... https://www.marshut.net/kuimwz/cog-in-the-cloud.html [1] http://wiki.xenproject.org/wiki/Cloud_Operating_Systems [2] http://wiki.squeak.org/squeak/1762 [3] http://wiki.xen.org/wiki/PvGrub [4] https://tech.mendix.com/linux/2014/09/06/pvgrub2/ http://ptgmedia.pearsoncmg.com/images/9780132349710/samplechapter/013234971X...
On 14 Jan 2015, at 08:15, Ben Coman <btc@openInWorld.com> wrote:
On Wed, Jan 14, 2015 at 11:39 AM, Joerg Beekmann, DeepCove Labs <joerg@deepcovelabs.com <mailto:joerg@deepcovelabs.com>> 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://www.openmirage.org/> http://queue.acm.org/detail.cfm?id=2566628 <http://queue.acm.org/detail.cfm?id=2566628> http://blog.acolyer.org/2015/01/13/unikernels-library-operating-systems-for-... <http://blog.acolyer.org/2015/01/13/unikernels-library-operating-systems-for-...>
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/ <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/ <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 <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 <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.ht... <http://lists.xenproject.org/archives/html/mirageos-devel/2015-01/msg00053.ht...>. 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/ <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 :) http://pillarhub.pharocloud.com/hub/mikefilonov/pharonos <http://pillarhub.pharocloud.com/hub/mikefilonov/pharonos>
btw, Did you see the discussion titled "Cog In The Cloud" http://forum.world.st/Cog-in-the-cloud-td4796515.html#a4796520 <http://forum.world.st/Cog-in-the-cloud-td4796515.html#a4796520> and a little bit extra at the bottom of this one... https://www.marshut.net/kuimwz/cog-in-the-cloud.html <https://www.marshut.net/kuimwz/cog-in-the-cloud.html>
[1] http://wiki.xenproject.org/wiki/Cloud_Operating_Systems <http://wiki.xenproject.org/wiki/Cloud_Operating_Systems> [2] http://wiki.squeak.org/squeak/1762 <http://wiki.squeak.org/squeak/1762> [3] http://wiki.xen.org/wiki/PvGrub <http://wiki.xen.org/wiki/PvGrub> [4] https://tech.mendix.com/linux/2014/09/06/pvgrub2/ <https://tech.mendix.com/linux/2014/09/06/pvgrub2/> http://ptgmedia.pearsoncmg.com/images/9780132349710/samplechapter/013234971X... <http://ptgmedia.pearsoncmg.com/images/9780132349710/samplechapter/013234971X...>
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 :)
http://pillarhub.pharocloud.com/hub/mikefilonov/pharonos <http://pillarhub.pharocloud.com/hub/mikefilonov/pharonos> But this one actually has a small Linux as the base⦠so it is not âNOSâ in this sense.
Marcus
On Wed, Jan 14, 2015 at 3:15 AM, Ben Coman <btc@openinworld.com> wrote:
On Wed, Jan 14, 2015 at 11:39 AM, Joerg Beekmann, DeepCove Labs <joerg@deepcovelabs.com> 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-...
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.ht.... 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.
btw, Did you see the discussion titled "Cog In The Cloud" http://forum.world.st/Cog-in-the-cloud-td4796515.html#a4796520 and a little bit extra at the bottom of this one... https://www.marshut.net/kuimwz/cog-in-the-cloud.html
[1] http://wiki.xenproject.org/wiki/Cloud_Operating_Systems [2] http://wiki.squeak.org/squeak/1762 [3] http://wiki.xen.org/wiki/PvGrub [4] https://tech.mendix.com/linux/2014/09/06/pvgrub2/
http://ptgmedia.pearsoncmg.com/images/9780132349710/samplechapter/013234971X...
-- best, Eliot
Le 14/01/2015 21:12, Eliot Miranda a écrit :
On Wed, Jan 14, 2015 at 3:15 AM, Ben Coman <btc@openinworld.com <mailto:btc@openinworld.com>> wrote:
On Wed, Jan 14, 2015 at 11:39 AM, Joerg Beekmann, DeepCove Labs <joerg@deepcovelabs.com <mailto:joerg@deepcovelabs.com>> 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-...
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.ht.... 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
btw, Did you see the discussion titled "Cog In The Cloud" http://forum.world.st/Cog-in-the-cloud-td4796515.html#a4796520 and a little bit extra at the bottom of this one... https://www.marshut.net/kuimwz/cog-in-the-cloud.html
[1] http://wiki.xenproject.org/wiki/Cloud_Operating_Systems [2] http://wiki.squeak.org/squeak/1762 [3] http://wiki.xen.org/wiki/PvGrub [4] https://tech.mendix.com/linux/2014/09/06/pvgrub2/
http://ptgmedia.pearsoncmg.com/images/9780132349710/samplechapter/013234971X...
-- best, Eliot
-- Regards, Alain
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)
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-...
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.ht.... 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
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-...
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.ht.... 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
participants (10)
-
Alain Rastoul -
Ben Coman -
Craig Latta -
Eliot Miranda -
Esteban Lorenzano -
Joerg Beekmann, DeepCove Labs -
Marcus Denker -
Norbert Hartl -
stepharo -
Sven Van Caekenberghe