Hey Anil,
On 13.09.2017 12:11, Anil Madhavapeddy wrote:
On 11 Sep 2017, at 13:08, Simon Kuenzer <simon.kuen...@neclab.eu> 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
others.
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
publish.
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!
regards,
Anil
Simon
[1] https://github.com/mirage/ocaml-freestanding/
_______________________________________________
Minios-devel mailing list
minios-de...@lists.xenproject.org
https://lists.xenproject.org/cgi-bin/mailman/listinfo/minios-devel
--
============================================================
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.kuen...@neclab.eu
============================================================
NEC Europe Ltd | Registered Office: Athene, Odyssey
Business Park, West End Road, London, HA4 6QE, GB
Registered in England 2832014
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
