Re: Future Direction of GNU Hurd?

[Olaf Buddenhagen]

Hi,

On Sat, Feb 20, 2021 at 12:07:27PM +1100, William ML Leslie wrote:
> On Sat, 20 Feb 2021 at 03:23, Olaf Buddenhagen <olafbuddenhagen@gmx.net> 
> wrote:

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

Yeah, I was thinking of "endpoint"... Indeed that's how I stumbled upon
the seL4 docs!

> The seL4 team were smart enough to pilfer plenty of design and
> terminology from Shap, so they have endpoints too.

Here's the thing: it appears that in seL4, an "endpoint" is the IPC port
itself -- with an endpoint capability referencing either the sender or
the receiver end. (Or both.)

However, if in Coyotos "endpoint" clearly denotes the receiver end, I
guess that's good enough for me in terms of precedent :-)

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

That's never been the plan, to the best of my knowledge... That would
remove most of the point of moving away from Mach.

The idea was just to implement *some* sort of capability-based IPC. (And
some sort of asynchronous communication ability...)

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

The message typing is really the least important aspect of Mach IPC
IMHO... What makes it pretty convenient for writing interfaces with
little abstraction, is the way in handles senders/receivers,
notification etc., in a way that feels very natural in most situations.
Unfortunately, that pretty much depends on the kernel buffering, as far
as I can tell -- so it's not really a good design in practice...

> There are definitely other impedance mismatches, but none of them are
> scary.

In my understanding, aside from the async communication question, the
main point of contention was the use of protected constructors: Marcus
ultimately concluded that they don't align with the GNU philosophy --
proposing a strictly hierarchical structure instead. (Much like what
Genode emerged with at around the same time, as I understand it...)

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

That's a no-brainer really: Neal came up with the concept specifically
to address the resource management issues with Hurd/Mach...

> The Single Level Store drivers in CapROS look like they have much more
> predictable behaviour than an adaptive cache.

Excuse my ignorance: but isn't the single level store concept closely
related to orthogonal persistence? That would be a controversial choice
for a Hurd-like system, to put it mildly...

-antrik-