Mailing List Archive

Re: [MirageOS-devel] [Minios-devel] [RFC] Unicore Subproject Proposal
On 13 Sep 2017, at 17:13, Samuel Thibault <samuel.thibault@ens-lyon.org> wrote:
>
> Hello,
>
> Anil Madhavapeddy, on mer. 13 sept. 2017 11:11:03 +0100, wrote:
>> Maintaining a forked MiniOS has been a multi-year source of a maintenance burden for MirageOS,
>
> I'm just wondering why this happened?
>
> The mini-os repository is open for development, it's just a matter of
> agreeing on how to implement features :)

We forked it well before mini-os spun out into a separate repository,
around 5 years ago. And then some features (such as arm32 support)
took around a year to be upstreamed due to multiple iterations of the
patchsets, and we just maintained it in our fork. None of this is
relevant any more in the brave new world of MiniOS being a separate
repository.

>
>> 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.
>
> That could already be a build option in MiniOS. It seems it actually
> already is, via $(CONFIG_XENBUS)=n.
>
> If launching UniCore allows to get momentum to achieve that, I'm all for
> it, I'm just wondering whether the problem is not actually about putting
> a name on it, but just discussing here what is needed, and see how to
> implement it all within the same repository. But again, I understand
> that putting a name can trigger that discussion and be a "let's do it!"
> message :)

It's a combination of both I think. I had a very quick look at the latest mini-os
tree and ran into build problems from the master branch
(e.g. just doing make results in:

gcc -fno-builtin -Wall -Werror -Wredundant-decls -Wno-format -Wno-redundant-decls -Wformat -fno-stack-protector -fgnu89-inline -Wstrict-prototypes -Wnested-externs -Wpointer-arith -Winline -g -D__INSIDE_MINIOS__ -m64 -mno-red-zone -fno-reorder-blocks -fno-asynchronous-unwind-tables -DCONFIG_PARAVIRT -DCONFIG_START_NETWORK -DCONFIG_SPARSE_BSS -DCONFIG_BLKFRONT -DCONFIG_NETFRONT -DCONFIG_KBDFRONT -DCONFIG_FBFRONT -DCONFIG_CONSFRONT -DCONFIG_XENBUS -D__XEN_INTERFACE_VERSION__=0x00030205 -isystem /src/include -D__MINIOS__ -isystem /src/include/x86 -isystem /src/include/x86/x86_64 -c lib/string.c -o /src/lib/string.o
lib/string.c: In function '__ffsti2':
lib/string.c:29:27: error: implicit declaration of function 'ffs' [-Werror=implicit-function-declaration]
if (num == 1) return (ffs((int) lli));
^~~
lib/string.c:29:5: error: nested extern declaration of 'ffs' [-Werror=nested-externs]
if (num == 1) return (ffs((int) lli));
^~
cc1: all warnings being treated as errors
make: *** [minios.mk:68: /src/lib/string.o] Error 1

and the various combinatorial removal of config options resulted in lots
of small problems that broke the build. I imagine Unicore's build system
could take a combination of feature flags and focus on make it easier
to maintain the many variants. Or perhaps MiniOS's could do the same by
improving the Travis file in the repository to test more combinations.
Either way, I didn't quite have the time to do any of that work myself
and I had to context switch to something else after running into the
build problem I'm afraid ;-)

regards,
Anil


_______________________________________________
Xen-api mailing list
Xen-api@lists.xen.org
https://lists.xen.org/cgi-bin/mailman/listinfo/xen-api
Re: [MirageOS-devel] [Minios-devel] [RFC] Unicore Subproject Proposal [ In reply to ]
> 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
Re: [MirageOS-devel] [Minios-devel] [RFC] Unicore Subproject Proposal [ In reply to ]
On 15.09.2017 11:35, Anil Madhavapeddy wrote:
>
>> On 15 Sep 2017, at 09:36, Simon Kuenzer <simon.kuenzer@neclab.eu
>> <mailto: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
>>> <mailto: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.

Yes, I agree. I am going to have a second round through the proposal.

>
> 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.

It might be handled in this way during the project start, however I see
Unicore more than just a set of base libraries to support language
runtimes. The main intention is to support applications natively written
to it and to support existing applications you may want to port.
For these cases you need more than a minimal base, you want to select a
libc, a certain scheduler, and most likely a TCP/IP stack, as well as
filesystem support. These libraries should work together and should also
work with the base libraries. Additionally, the requirements to the
libraries might differ among the projects.
Our content cache node Unikernel (called MiniCache), for instance, uses
newlibc and lwIP. On top we have developed a single-purpose filesystem
and web server code. Together we could achieve impressive performance
results by using a single CPU compared to traditional web server
applications running on a traditional OS [1].

In sum, the aim with Unicore is to have fine-granularity libraries so
that it's flexible enough to accommodate a wide range of unikernels.
Because of this, I see Unicore as having potential to eventually replace
MiniOS.

>
> regards,
> Anil
>

Thanks,

Simon


[1] http://dl.acm.org/citation.cfm?doid=3050748.3050757

--
============================================================
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@neclab.eu
============================================================
NEC Europe Ltd | Registered Office: Athene, Odyssey
Business Park, West End Road, London, HA4 6QE, GB
Registered in England 2832014

_______________________________________________
Xen-api mailing list
Xen-api@lists.xen.org
https://lists.xen.org/cgi-bin/mailman/listinfo/xen-api