> On 15 Sep 2017, at 09:36, Simon Kuenzer <simon.kuen...@neclab.eu> wrote:
> 
> 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 ;-).

This sounds good. It's worth thinking through the explicit differences in goals 
from MiniOS, to address Samuel's points.

It seems to me that MiniOS should remain the primary "support kernel" for 
Xen-related activities, for instance as a stub domain support kernel.  Unicore 
on the other hand explicitly tries to parameterise across its configuration so 
that it can be library linked to language runtimes more easily.

This split may help simplify MiniOS by removing some of the pseudo libc code 
that may be unnecessary outside Xen support functions, and also let us package 
up language runtimes in Unicore more easily via simple library package 
management and cross compilation.

regards,
Anil

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Reply via email to