Hi Alexander,
thanks a lot for your review.
On 10.09.2017 22:48, Alexander Dubinin wrote:
Hi Felipe, all,
Great that it's going to start :) Looking forward to join :)
I am looking forward to your contributions. ;)
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.
2. Does any security subsystem planned? XEN have XSM/FLASK, but IMHO is
should be supplemented by some security layer in control/stub domains as
well. So far only known implementation is OpenXT, but it is.... very
specific. Probably some generalized security layer needed in Unicore to
supplement FLASK/XSM... Correct me please, if I misunderstanding :)
I agree that many projects (especially embedded, stubdomains, driver
domains, NFV) have a vested interest in security and isolation. In my
view, XSM/FLASK further restricts what a VM can do and sounds kind of
orthogonal to the functionality of a VM (am I right?). The fact that
Unikernels should only pick components that are actually required to do
the job reduces the attack surface compared to general purpose OSes.
Do you see further value with FLASK/XSM which requires early
implementation and design decisions for Unicore? As far as I can tell
something like Flask is implemented mostly in the hypervisor and
toolstack, not in the guests themselves, is this right?
Thanks,
Simon
Regards,
Alexander
On Fri, Sep 8, 2017 at 3:31 PM, Felipe Huici <felipe.hu...@neclab.eu
<mailto:felipe.hu...@neclab.eu>> wrote:
Hi Wei, Stefano,
Thank you so much for agreeing to be sponsors! I’ll update the document.
— Felipe
============================================================
Dr. Felipe Huici
Chief Researcher, Networked Systems and Data
Analytics Group
NEC Laboratories Europe, Network Research Division
Kurfuerstenanlage 36, D-69115 Heidelberg
Tel. +49
(0)6221 4342-241
Fax: +49
(0)6221 4342-155
e-mail:
felipe.hu...@neclab.eu <mailto:felipe.hu...@neclab.eu>
============================================================
NEC Europe Limited Registered Office: NEC House, 1
Victoria Road, London W3 6BL Registered in England 2832014
On 9/8/17, 1:00 PM, "Lars Kurth" <lars.ku...@citrix.com
<mailto:lars.ku...@citrix.com>> wrote:
>@Wei, @Stefano,
>
>On 07/09/2017, 22:16, "Stefano Stabellini" <sstabell...@kernel.org
<mailto:sstabell...@kernel.org>> wrote:
>
> Hi all,
>
> I would be glad to sponsor this proposal. I think it will be
of great
> benefit to the ecosystem. Let me know if I need to do anything
>specific.
>
>Basically, all which is needed is an agreement. Which we have from you
>both. Felipe, can then add your names to the proposal.
>
>Looking out for the evolving project and helping (e.g. through
advice) is
>not strictly necessary, but always welcome.
>
>Lars
>
--
Regards,
Alexander Dubinin
--
============================================================
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
