From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anil Madhavapeddy Subject: Re: [MirageOS-devel] [Minios-devel] [Xen-API] [RFC] Unicore Subproject Proposal Date: Fri, 15 Sep 2017 10:35:18 +0100 Message-ID: <2D459324-0C16-4386-A74E-EDEBB7EC58BB@recoil.org> References: <3BAA91DD-A37A-43E3-833B-1E7DEE85FB19@citrix.com> Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Content-Type: multipart/mixed; boundary="===============6782454653765689320==" Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xen.org Sender: "Xen-devel" To: Simon Kuenzer Cc: Felipe Huici , Lars Kurth , Stefano Stabellini , "rshaposhnik@pivotal.io" , "xen-api@lists.xenproject.org" , Saverio Niccolini , "minios-devel@lists.xenproject.org" , Alexander Dubinin , "julien.grall@arm.com" , "committers@xenproject.org" , "mirageos-devel@lists.xenproject.org" , "stefano@aporeto.com" , "xen-devel@lists.xenproject.org" , "volodymyr_babchuk@epam.com" List-Id: xen-devel@lists.xenproject.org --===============6782454653765689320== Content-Type: multipart/alternative; boundary="Apple-Mail=_9B12EA50-3FE5-4B75-AB43-448760BB115C" --Apple-Mail=_9B12EA50-3FE5-4B75-AB43-448760BB115C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 15 Sep 2017, at 09:36, Simon Kuenzer = wrote: >=20 > Hey Anil, >=20 > On 13.09.2017 12:11, Anil Madhavapeddy wrote: >> On 11 Sep 2017, at 13:08, Simon Kuenzer = wrote: >>>=20 >>>> 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 :) >>>=20 >>> 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. >>>=20 >>> 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. >>>=20 >> 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. >=20 > 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. >=20 > 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 --Apple-Mail=_9B12EA50-3FE5-4B75-AB43-448760BB115C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On 15 Sep 2017, at 09:36, Simon Kuenzer <simon.kuenzer@neclab.eu> wrote:

Hey Anil,

On 13.09.2017 12:11, Anil Madhavapeddy = wrote:
On 11 Sep 2017, at 13:08, Simon Kuenzer <simon.kuenzer@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

= --Apple-Mail=_9B12EA50-3FE5-4B75-AB43-448760BB115C-- --===============6782454653765689320== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVs IG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwczovL2xpc3RzLnhlbi5v cmcveGVuLWRldmVsCg== --===============6782454653765689320==--