gesimu at gmail.com
Sun Aug 11 22:05:03 CEST 2019
Not sure if someone else already replied directly to you, but I'll
give my two cents anyway :)
Barrelfish already utilizes Exokernel principles in the sense that
user applications by default link against libbarrelfish. libbarrelfish
acts as a library OS which provides higher-level convenience
abstractions around the raw Barrelfish syscall interface which is
built around seL4-like capabilities and not particularly
user-friendly. Note however, that applications are not required to
link against libbarrelfish. However, most applications do, as
libbarrelfish abstracts away quite a lot of boilerplate which the
Barrelfish architecture brings, such as tedious capability-based
memory management, message channel setup, message and event handling,
etc. Note that even applications which link against libbarrelfish can
still interact with the lower-level interfaces to implement features
which are not provided out of the box by libbarrelfish, e.g.
copy-on-write memory regions.
One area where Barrelfish could be improved from an engineering
perspective is the modularity of the library OS could be vastly
improved, and libbarrelfish could be split in multiple more or less
loosely coupled libraries which applications can individually link
against. However, the coupling of libbarrelfish is quite tight in
places, and some parts are quite interlinked out of necessity, e.g.
memory management and cspace management.
So, to answer your question in short, while the multikernel design
doesn't say anything about exokernel or not, its implementation in
Barrelfish is already a "exo-multikernel" if you wish, as the CPU
drivers themselves were kept rather small right from the beginning.
Hope this helps,
On Tue, 2 Jul 2019 at 00:06, Arnkjell Eriksen
<arnkjell.eriksen at outlook.com> wrote:
> Would an exo-multikernel make sense or be feasible?
> Barrelfish-users mailing list
> Barrelfish-users at lists.inf.ethz.ch
More information about the Barrelfish-users