Re: Future Direction of GNU Hurd?

[Olaf Buddenhagen]

Hi,

On Fri, Nov 27, 2020 at 04:41:28PM -0800, Jonathan S. Shapiro wrote:

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

I'm glad to hear it :-)

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

I can't answer that for sure: but for what it's worth, when I recently
glanced over the seL4 documentation (while looking for clarity on some
terminology), my impression was that it wouldn't be a very good fit for
a Hurd-like architecture... Or maybe I'm just lacking imagination ;-)

(BTW, I didn't get the desired clarity: but perhaps you could chime in?
Is there a good generic term for a capability referencing the receive
end of an IPC port, such as the receive right in Mach?...)

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

I do believe that was the plan? The issue was that the cost of the
user-space services that would be needed to properly run a Hurd-like
architecture on top of the original L4 (without kernel capability
support) turned out to be prohibitive...

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

This is partially true...

The original Hurd does use Mach's kernel-buffered IPC. However, as far
as I can tell, Neal and Marcus knew from the beginning that kernel
buffering would have to go when porting to any modern kernel. The
question was what to replace it with, in order to still provide the
needed asynchronous functionality...

In the end, Neal's experimental "Viengoos" kernel used an approach where
the receiver (not the kernel) provides a receive buffer: but the receive
operation can nevertheless happen asynchronously from the receiver's
application threads. (Using some sort of activation-based mechanism --
though I'm not sure about the details.)

-antrik-