[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Future Direction of GNU Hurd?

From: Jonathan S. Shapiro
Subject: Re: Future Direction of GNU Hurd?
Date: Fri, 27 Nov 2020 16:41:28 -0800

On Wed, Oct 14, 2020 at 2:27 AM Olaf Buddenhagen <olafbuddenhagen@gmx.net> wrote:
However, as challenges became apparent with these newer kernels as well,
the bigger takeaway was that a design based on someone else's kernel
will always be constrained in some ways... The conclusion being that while any new attempt to
get the Hurd on a more modern kernel should certainly use learnings from
other projects, it would likely be better off implementing its own
kernel, specifically tailored to the envisioned design.

It may surprise you that I agree. Any kernel - even one that is trying to be "policy free" - makes architectural choices for one reason or another. These choices may be good or bad, and they may support your needs or not. When L4 and Coyotos were examined, I think the hope was that they might provide a directly useful base. Coyotos, at the time, didn't provide some things that the Hurd wanted. L4 likewise. It's possible that modern L4 variants might produce a different result.

But the other side of the coin is that both of these kernels took decades of work to get right (each by its own definition of right). Building your own kernel is not a small decision.

I also believe that there may have been some misunderstanding about L4, because it was never going to be possible to adopt "the L4 kernel". At best, it would be possible to adopt the L4 kernel and then structure some core resource management services around it that were designed to support the requirements of the Hurd. It was never clear to me if that was how the L4 option was approached.

It was a long time ago, now, so my memory is not clear, but I think one of the major disconnects was message buffering. Both L4 and Coyotos take the position that buffering in the kernel is a fundamentally bad idea. In most cases, it reduces performance and adds an opportunity for resource denial of service that is inherent in kernel buffering. Both Coyotos and L4 take the position that buffering is usually a bad thing to do. But when it must be done, it should be done by some user-mode application, and should be done using storage that the application is obtaining from some properly accounted source. Though it arrived too late to be helpful for Hurd, the Coyotos "event" and scheduler activation ideas were originally prompted by some of the Hurd discussions.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]