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

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


It looks to me as if there is some feedback: so it may make some sense to 
incorporate some of it and send out a version 2. We may also want to CC some 
reps from other unikernel projects but Mirage OS. Or you could point them to 
this thread in a separate mail through respective channels or a hub like 
unikernel.org. Whatever you think may work best. It’s your call.

And then have a formal vote, a week after v2 of the proposal. Does this work?


On 11/09/2017, 05:08, "Simon Kuenzer" <simon.kuenzer@xxxxxxxxx> wrote:

    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 
    > 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?
    > Regards,
    >    Alexander
    > On Fri, Sep 8, 2017 at 3:31 PM, Felipe Huici <Felipe.Huici@xxxxxxxxx 
    > <mailto:Felipe.Huici@xxxxxxxxx>> wrote:
    >     Hi Wei, Stefano,
    >     Thank you so much for agreeing to be sponsors! I’ll update the 
    >     — 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.huici@xxxxxxxxx <mailto:felipe.huici@xxxxxxxxx>
    >     ============================================================
    >     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.kurth@xxxxxxxxxx
    >     <mailto:lars.kurth@xxxxxxxxxx>> wrote:
    >      >@Wei, @Stefano,
    >      >
    >      >On 07/09/2017, 22:16, "Stefano Stabellini" <sstabellini@xxxxxxxxxx
    >     <mailto:sstabellini@xxxxxxxxxx>> 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 
    >      >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.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®.