[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [Minios-devel] [Xen-API] [RFC] Unicore Subproject Proposal

Hey Anil,

On 13.09.2017 12:11, Anil Madhavapeddy wrote:
On 11 Sep 2017, at 13:08, Simon Kuenzer <simon.kuenzer@xxxxxxxxx> wrote:

Just my 2 cents:
1. Is this academic project, or it have specific goals and areas of 
application? Would be good to have some practical use-cases and well formulated 
list of problems (we all feel these by guts, but...), it aiming to solve. IMHO 
that will help to prioritize functionality and get usable result faster :)

It is kind of both, however we aim a strong focus on real world problems: IoT, 
Mobile Edge Computing (MEC), Automotive, Virtual Network Functions (VNFs), and 
We have played with many Unikernels (ClickOS, Mirage, Rump, OSv, and others) 
and tried to apply them in the several areas. While doing this, we noticed that 
each area benefits differently from the properties that Unikernels give - which 
is great (e.g., instant boot times for MEC, high performance for NFV, resource 
efficiency for IoT). However, building and maintaining new Unikernels (as we 
did with ClickOS, MiniCache, and Minipython) is currently painful.
Because of different focuses on properties and ported/implemented applications, 
most Unikernel today are bound to their own OS layers (e.g., ClickOS uses a 
different Mini-OS than Mirage). Each application requires a different subset of 
OS layers but also enables different optimizations of them.

In order to solve this, we came up with the Unicore proposal. But I agree with 
your suggestion at this point: It helps for the project start to focus on some 
initial areas. For now, I hope this is driven by the first contributors, and I 
have personally IoT in mind. Since the project goal is so ambitious, we should 
keep the long-term goal in mind from the beginning.

Thanks very much for kicking off this initiative. Maintaining a forked MiniOS 
has been a multi-year source of a maintenance burden for MirageOS, and we would 
love to be more aligned with an upstream version and benefit from new features 
such as (e.g.) HVM booting.

We have the same burden with ClickOS and all the other unikernels we have built. Features like HVM booting or support for different hypervisors, are always something that users ask for. Since many Unikernel projects struggle with this, I would like to have the maintenance effort of a common base concentrated. But we also learned that each Unikernel has own requirements: This is why Unicore has to provide full configuration flexibility. Only then, all Unikernel projects could really benefit from it.

So, I think we should all focus on the Unicore base and make our individual projects successful with it ;-).

 From a MirageOS perspective, we'd be happy to switch to something that can 
give us just enough MiniOS for our ocaml-freestanding [1] code to boot on Xen.  
One requirement from our side is that we need to strip down MiniOS to remove 
even the C xenstore implementation, since we have pure OCaml gnt, xenstore and 
device driver implementations.  We'd be happy to try out an alpha Unicore and 
let you know what is in excess to our needs as soon as you have something to 

Sure, lets do this! ;-) This is perfectly inline with the goals we target with the Unicore build system.

So full support from MirageOS for this initiative!

Thank you so much!



[1] https://github.com/mirage/ocaml-freestanding/

Minios-devel mailing list

Simon Kuenzer
シモン クゥンツァー
Research Scientist,
Networked Systems and Data Analytics Group
NEC Laboratories Europe, Network Research Division
Kurfuerstenanlage 36, D-69115 Heidelberg
Tel.     +49 (0)6221 4342-264
Fax:     +49 (0)6221 4342-5264
e-mail:  simon.kuenzer@xxxxxxxxx
NEC Europe Ltd | Registered Office: Athene, Odyssey
Business Park, West End Road, London, HA4 6QE, GB
Registered in England 2832014

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.