Re: Future Direction of GNU Hurd?

--000000000000f2ed2705bc41f606
Content-Type: text/plain; charset="UTF-8"

On Fri, Feb 19, 2021 at 8:23 AM Olaf Buddenhagen <[email protected]>
wrote:

> (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?...)
>

Not that I know of. One of the critical notions in capabilities is that the
capability you wield names the object you manipulate. If the receive port
can be transferred, this intuition is violated. In consequence, few
capability-bases systems have implemented receive ports.

No member of the KeyKOS family implemented such a notion. Coyotos comes
closest. "Entry" capabilities actually point to Endpoint objects, which in
turn contain a Process capability to the implementing process. A scheduler
activation is performed within this process. This is comparable to a
receive port capability because the process capability within the Endpoint
object can be updated.

I went back and forth for a long time about how multiple processes might
wait on a common receive port. The problem with this is that the objects
implemented by these processes tend to have state, so if successive
invocations can go to any of the participant processes you end up in a
multi-threading shared memory regime anyway. When this takes the invocation
across a CPU to CPU boundary, the cache coherency costs can be higher than
the total invocation cost. We decided it would be better to use scheduler
activations and an event-driven approach, and let the receiving process
make its own decisions about threading.

This also has the advantage that all of the "pointers" (the object
references) point from the invoker to the invokee. That turns out to be
essential if you want to implement transparent orthogonal persistence. It
rules out receive port capabilities.


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

I can believe that. The introduction of kernel capability support was an
outcome of the "L4 Capability Summit" meeting in Dresden in 2004 (if I
recall correctly), but it took several years for the results to show up in
actual implementations. It wasn't a small architectural change.


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

I have not looked at Viengoos, but this sounds functionally similar to what
Coyotos does. In Coyotos, the receiving process designates a scheduler
activation block that says where the incoming data should go.


Jonathan

--000000000000f2ed2705bc41f606
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr">On Fri, Feb 19, 2021 at 8:23 AM Olaf Budd=
enhagen &lt;<a href=3D"mailto:[email protected]">olafbuddenhagen@gmx.=
net</a>&gt; wrote:<br></div><div class=3D"gmail_quote"><blockquote class=3D=
"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(2=
04,204,204);padding-left:1ex">(BTW, I didn&#39;t get the desired clarity: b=
ut perhaps you could chime in?<br>
Is there a good generic term for a capability referencing the receive<br>
end of an IPC port, such as the receive right in Mach?...)<br></blockquote>=
<div><br></div><div>Not that I know of. One of the critical notions in capa=
bilities is that the capability you wield names the object you manipulate. =
If the receive port can be transferred, this intuition is violated. In cons=
equence, few capability-bases systems have implemented receive ports.</div>=
<div><br></div><div>No member of the KeyKOS=C2=A0family implemented such a =
notion. Coyotos comes closest. &quot;Entry&quot; capabilities actually poin=
t to Endpoint objects, which in turn contain a Process capability to the im=
plementing process. A scheduler activation is performed within this process=
. This is comparable to a receive port capability because the process capab=
ility within=C2=A0the Endpoint object can be updated.</div><div><br></div><=
div>I went back and forth for a long time about how multiple processes migh=
t wait on a common receive port. The problem with this is that the objects =
implemented by these processes tend to have state, so if successive invocat=
ions can go to any of the participant processes you end up in a multi-threa=
ding shared memory regime anyway. When this takes the invocation across a C=
PU to CPU boundary, the cache coherency costs can be higher than the total =
invocation cost. We decided it would be better to use scheduler activations=
 and an event-driven approach, and let the receiving process make its own d=
ecisions about threading.</div><div><br></div><div>This also has the advant=
age that all of the &quot;pointers&quot; (the object references) point from=
 the invoker to the invokee. That turns out to be essential if you want to =
implement transparent orthogonal persistence. It rules out receive port cap=
abilities.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D=
"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-le=
ft:1ex">&gt; I also believe that there may have been some misunderstanding =
about L4,<br>
&gt; because it was *never* going to be possible to adopt &quot;the L4 kern=
el&quot;. At<br>
&gt; best, it would be possible to adopt the L4 kernel and then structure s=
ome<br>
&gt; core resource management services around it that were designed to supp=
ort<br>
&gt; the requirements of the Hurd. It was never clear to me if that was how=
 the<br>
&gt; L4 option was approached.<br>
<br>
I do believe that was the plan? The issue was that the cost of the<br>
user-space services that would be needed to properly run a Hurd-like<br>
architecture on top of the original L4 (without kernel capability<br>
support) turned out to be prohibitive...<br></blockquote><div><br></div><di=
v>I can believe that. The introduction of kernel capability support was an =
outcome of the &quot;L4 Capability Summit&quot; meeting in Dresden in 2004 =
(if I recall correctly), but it took several years for the results to show =
up in actual implementations. It wasn&#39;t a small architectural change.</=
div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px =
0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">In t=
he end, Neal&#39;s experimental &quot;Viengoos&quot; kernel used an approac=
h where<br>
the receiver (not the kernel) provides a receive buffer: but the receive<br=
>
operation can nevertheless happen asynchronously from the receiver&#39;s<br=
>
application threads. (Using some sort of activation-based mechanism --<br>
though I&#39;m not sure about the details.)<br></blockquote><div><br></div>=
<div>I have not looked at Viengoos, but this sounds functionally similar to=
 what Coyotos does. In Coyotos, the receiving process designates a schedule=
r activation block that says where the incoming data should go.=C2=A0</div>=
<div><br></div><div><br></div><div>Jonathan</div></div></div>

--000000000000f2ed2705bc41f606--