- force all xcall(9) API consumers to pass dynamically allocated
arguments, a bit like workqueue(9) enqueues works. Scheduling
xcall(9) is now managed by a SIMPLEQ() of requests.
- extends softint(9) API so we can pass arguments to it as well as
the targetted CPU(s) (optional argument).
The last two points make me think that the softint(9), workqueue(9)
and xcall(9) APIs have a potential for unification; all of these are
somewhat redundant, they all schedule/signal/dispatch stuff to other
threads, albeit under different conditions though.

IIRC, the document does not contemplate putting xcall(9) under
the proposed kernel-continuations framework, but it does mention
both softints and workqueues as candidates for unification under
continuations.

Interesting reading; and yes, it seems to be case. Cross calls and
softints are functionally close: they dispatch works to other threads,
but softint(9) cannot pass arguments whereas xcall(9) do. From an
implementation PoV, xcall and sofint are CPU-bound threads nowadays,
with additional strong requirements for softints (cannot sleep,
lightweight, mapped to interrupt level priorities). xcall threads are
just plain kernel threads.

The last part of the page is also worth a look. I remember a PoC on L4
kernels for "single/merge kernel stack" implementations, and matt's idea
is close to this too.

Lots of ideas, so little time for me :(
--
Jean-Yves Migeon
jeanyves.migeon%free.fr@localhost