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 <[email protected]> wrote: > Le 15/01/2015 20:58, Joerg Beekmann, DeepCove Labs a écrit : > > >> >> >>>> -----Original Message----- >>>>> From: Pharo-dev [mailto:[email protected]] On Behalf >>>>> Of Alain Rastoul >>>>> Sent: Wednesday, January 14, 2015 10:39 PM >>>>> To: [email protected] >>>>> 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 > > >
