is L4 an all around better choice for MINIX?

[Garegin Asatryan]

As far as I understand, L4 solves the performance issues that plagues traditional microkernels like mach, hurd and minix. doesn't that make minix's kernel "dead in the water"? Do you think that adopting L4 would be a good idea, or are where any reasons why its not suitable for MINIX?

[Thomas Cort]

> performance issues that plagues traditional microkernels like mach, hurd and minix.

I don't think the performance hit caused by the microkernel
architecture really "plagues" Minix. I've never seen anyone complain
that Minix is too slow or unusable.

> doesn't that make minix's kernel "dead in the water"?

Not for me. For a lot of use cases, reliability trumps a small
performance hit. I'd rather have apps on my phone run slightly slower
(maybe even 50% slower) than have it reboot randomly when I'm in the
middle of doing something important (which it currently does).

> Do you think that adopting L4 would be a good idea, or are where any reasons why its not suitable for MINIX?

There are probably tons of technical reasons why one might be better
than the other for certain use cases, but I don't know anything about
L4 so I'll just give a non-technical reason for why I don't think it's
a good idea...

Over the past few years, Minix has been replacing the userland with
components from NetBSD. This improves compatibility and lets the
developers focus on the interesting bits -- the kernel and servers.
For example, the developers can focus on live update instead of adding
options to the `cp` command to make it compatible with some other OS's
`cp` command. Most of what's left of Minix is the kernel, servers, and
drivers. Those are all designed around the Minix kernel. If that was
replaced by L4, there'd be no Minix left -- it would just be a NetBSD
userland with an L4 kernel. It would be throwing away 28 years of
research and development.

TC

> --
> You received this message because you are subscribed to the Google Groups
> "minix3" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to minix3+un...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Tomas Hruby]

> Not for me. For a lot of use cases, reliability trumps a small
> performance hit. I'd rather have apps on my phone run slightly slower
> (maybe even 50% slower) than have it reboot randomly when I'm in the
> middle of doing something important (which it currently does).

Ohhh, I would like them to run 50% faster :-)))

>> Do you think that adopting L4 would be a good idea, or are where any reasons why its not suitable for MINIX?
>
> There are probably tons of technical reasons why one might be better
> than the other for certain use cases, but I don't know anything about
> L4 so I'll just give a non-technical reason for why I don't think it's
> a good idea...
>
> Over the past few years, Minix has been replacing the userland with
> components from NetBSD. This improves compatibility and lets the
> developers focus on the interesting bits -- the kernel and servers.
> For example, the developers can focus on live update instead of adding
> options to the `cp` command to make it compatible with some other OS's
> `cp` command. Most of what's left of Minix is the kernel, servers, and
> drivers. Those are all designed around the Minix kernel. If that was
> replaced by L4, there'd be no Minix left -- it would just be a NetBSD
> userland with an L4 kernel. It would be throwing away 28 years of
> research and development.

Honestly, the kernel does not make Minix what Minix is. The userspace
servers, the system overall design, that is what makes it unique.
Whether is runs on top of L4 or Barrelfish is IMHO not important, the
same idea can be implemented on top of any microkernel. For instance,
seL4 kernel would provide additional degree or reliability. Sure,
there are implementation dependencies so a switch would not be
straight forward. Nobody knows whether L4 would be a better choice
because there is no such system like Mnix implemented on top of L4.
microkernel does imply the same design as MInix. Plus the biggest
performance bottleneck is likely not the kernel itself.

[Antoine LECA]

On 2015-01-31 14:45Z, Thomas Cort wrote:
>> performance issues that plagues traditional microkernels like mach, hurd and minix.
>
> I don't think the performance hit caused by the microkernel
> architecture really "plagues" Minix. I've never seen anyone complain
> that Minix is too slow or unusable.

I do complain that Minix 3.2 is too slow. However, my reference point
was Minix 3.1.2, and the performance problem was not because of the
micro-kernel architecture, rather because the application I am using
were using a memory model (lots of exec using very big executables were
only very small parts are used, typical of C++ programming) which are
quite expensive on Minix 3.2 (forcing memory copying of lots of pages)
while seems cheap on classical *nix designs (using demand load.)

>> Do you think that adopting L4 would be a good idea, or are where
>> any reasons why its not suitable for MINIX?
>

> Over the past few years, Minix has been replacing the userland with
> components from NetBSD. This improves compatibility and lets the
> developers focus on the interesting bits -- the kernel and servers.

> [...] Most of what's left of Minix is the kernel, servers, and

> drivers. Those are all designed around the Minix kernel. If that was
> replaced by L4, there'd be no Minix left -- it would just be a NetBSD
> userland with an L4 kernel.

Well, no. If one replaces Minix's kernel with L4's kernel, one still
needs the Minix servers, adjusted to work with L4 instead.

And the result will still be Minix, with Minix's speed and Minix's look
and feel.

Basically the same thing occurred when the kernel evolved between the
"integrated" design of Minix 1 and 2 (with drivers in kernel address
space) and 3.0.x with drivers as services, and evolved another time when
kernel was completely revamped to include SMP facilities, during the
3.1.x evolution.


Antoine

[Antoine LECA]

On 2015-01-31 13:10Z, Garegin Asatryan wrote:
> As far as I understand, L4 solves the performance issues that plagues
> traditional microkernels like mach, hurd and minix.

Facts? Data?

Your assertion does not even define the concept you are using, like the
use of "traditional." You are comparing a minimal kernel-only design
with three different operating systems; so the most evident meaning you
are giving to "traditional" is usually written "complete" in English.

And then your sentence does not make any sense.

> doesn't that make minix's kernel "dead in the water"?

No. L4 is historically an off-shot of Mach. So starting from your
assertion above reduced to Mach ("L4 solves the performance issue of
Mach"), the conclusion would rather be the emerging of an evolution of
Minix's kernel (to 'solve issues') rather than making it dead.

Of course, we know that it is not what you probably mean; what you are
proposing is to replace Minix's kernel with L4. Which is a possible
alternate design. L4 is widely known since 1993, and is widely usable
for more than 15 years now. L4/Minix was a reality about 10 years ago.
But Minix is still here with its own kernel.

So no, L4 and its improved performances *did* not kill MINIX's kernel.

> Do you think that adopting L4 would be a good idea,

I dislike the word "adopting", but yes, I believe that bolting MINIX on
top of L4 could be a good idea.

> or are where any reasons why its not suitable for MINIX?

Not that I know.
Bottom line, I believe L4/Minix3 would be a *good idea* (nothing more,
nothing less.) Put otherwise, I am sure that if you show a new release
of Minix 3.3 running on top of L4 (or seL4, or Pistacchio, or Fiasco),
there will be interest from the other developers of MINIX.


Antoine

[Urfin Juice]

http://research.nii.ac.jp/~kazuya/L4.Minix/index.html

[Urfin Juice]

http://research.nii.ac.jp/~kazuya/L4.Minix/index.html