Re: Future Direction of GNU Hurd?

[William ML Leslie]

On Sat, 20 Feb 2021 at 03:23, Olaf Buddenhagen <olafbuddenhagen@gmx.net> wrote:
>
> 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 don't know if there's a generic term.  In Coyotos we have the
endpoint.  A process can have several endpoints that it is willing to
receive from.  I don't think we have anything normative about how to
have several processes listen to a single endpoint, so the concept
doesn't map cleanly to mach receive rights.  The seL4 team were smart
enough to pilfer plenty of design and terminology from Shap, so they
have endpoints too.

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

IME so far, you don't have to implement all of Mach IPC.  Mach IPC may
be a beautiful mostly-asynchronous channel supporting large,
sophisticated message types; but in practice the interfaces that Hurd
provides are not that ugly, and neither are those that GNU Mach
implements.  If there were situations where we'd have to split a Mach
message across two or more Coyotos or seL4 messages, we could build
that into MIG.  Having MIG as almost a level of indirection helps
quite a lot.

The part that is real work that I've seen so far is that Mach
implements virtual memory, and at a very different level to Coyotos or
L4.  The interface provided to pagers and their clients is very
high-level, and is similar to the structure you get from GNU pmap.
"This processes address space contains file ld.so from virtual address
0x636f796f746f7300" etc.  And then of course it can handle COW and
lazy initialisation for you.  On the other hand, the interface you get
from Coyotos is everything you need to securely build a
slightly-abstracted page table by hand.  Coyotos includes a
not-quite-working implementation of half a COW (c.f.
VirtualCopySpace), but it has been a good tutorial for me on how to
proceed, and a good reminder of how much work needs to be done.

There are definitely other impedance mismatches, but none of them are
scary.  In the same way the hurd process server does some accounting
to make Mach tasks look like Unix processes, some work is needed to
combine Coyotos processes and GPTs into a single unix process.

Oh, and I really mean that this has been the part that means real work
/so far/.  I feel like there are still loads of open design questions
that the Coyotos design process didn't answer.  You can see some of
this in the Coyotos Window System abstract.  For me, I expect that
once I port the hurd filesystem driver to Coyotos, I'll really want to
replace much of it, since it feels kind of magical to me and I'd
rather give applications more explicit control over caching and other
usage patterns, as Viengoos was trying to do.  The Single Level Store
drivers in CapROS look like they have much more predictable behaviour
than an adaptive cache.

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


-- 
William Leslie

Q: What is your boss's password?
A: "Authentication", clearly

Notice:
Likely much of this email is, by the nature of copyright, covered
under copyright law.  You absolutely MAY reproduce any part of it in
accordance with the copyright law of the nation you are reading this
in.  Any attempt to DENY YOU THOSE RIGHTS would be illegal without
prior contractual agreement.