GitLab

There is no point in using 64bit long Cobalt handles internally on
64bit platforms. However it makes sense to keep them as 32bit values
so that we may use them as atomic operands on either sides of a
64bit(kernel) <-> 32bit(user) ABI.

At this chance, boilerplate/atomic.h is sanitized for disambiguating
regular and long atomic set/get operations.

Consistency checks which monitor how applications behave (and not how
the Cobalt kernel behaves) are better grouped under a single switch,
i.e. CONFIG_XENO_OPT_DEBUG_USER.

Now that we have a compact core system, having most of the internal
consistency checks enabled via a single switch is developer-friendly -
i.e. so that we don't inadvertently miss a disabled assertion -
provided this keeps the overhead low.

This patch merges the former NUCLEUS and RTDM debug levels into the
COBALT one.

ipipe_raise_mayday() is the generic API call to handle this, and for
this reason, there should not be any arch-specific client code
required for this feature.

This patch introduces the client-side handler for the fast syscall
routing feature available with the upcoming pipelines.

A fastcall handler (i.e. ipipe_fastcall_hook) is immediately called
from the low level trap code, for handling a client syscall issued by
a thread which executes from the primary domain, instead of going
through the slower pipelined path.

- the fastcall handler is invoked for Cobalt syscalls as defined in
  include/cobalt/uapi/syscalls.h only, otherwise the syscall is passed
  to ipipe_syscall_hook.

- the fastcall handler may migrate the caller to the root domain if
  required.

- no propagation is possible from the fastcall handler to the regular
  kernel syscall code, i.e.: ipipe_fastcall_hook shall succeed or fail
  handling the syscall, but may not offload it to the regular kernel
  by returning KEVENT_PROPAGATE.

- if the pipeline does not support fastcall routing,
  ipipe_syscall_hook is invoked for handling all syscalls as
  previously.

We should have received the internal handshake from the spawned child
we wait for in pthread_create_ex() within 5s, or something definitely
went wrong. If we did not, time out and bail out with -EAGAIN so that
we don't remain stuck indefinitely on an internal problem.