Signals (Partial)

[garethodickin]

Developer Contact Info:

anderson.choi@boeing.com

Internal MR link

tbd

Licensing

OSS Approved for Upstream

Feature request summary

* Symbols (3): kill, sigtimedwait, sigwaitinfo
* Root cause: Signal subsystem needs config enabled; some signals (SIGSTOP, SIGCONT) unsupported; SIGTERM fails
* Fix: Enable signal config, add missing signal handling for required signals

Describe alternatives

Related architectures

arm64

Related platforms

Xen and Qemu

Additional context

kill() SIGSTOP/SIGCONT: Not supported.
kill() SIGTERM: In uk_signal_deliver(), exit_ctx->execenv is NULL, returning "no signal delivered". FIXME comment exists at this location.

sigtimedwait()/sigwaitinfo(): rt_sigtimedwait rejects call with errno=22 - sigsetsize(8) vs sizeof(sigset_t)(128). Even bypassing the size check, main thread cannot find the child thread to signal, child thread waits indefinitely.

[michpappas]

Regarding this one, as well as #1846 and #1840: (1) Right now signals are only supported on bin-compat mode, i.e. when loading ELF binaries with app-elfloader. (2) There is no arm64 bin-compat support yet. Does the use case involve bin-compat or native builds (i.e. unikraft and application compiled together into a single binary)?

In addition to the above, can you provide some context on the use case? Is that related to ARINC 653? If so, what is the general objective? Overall, signals like SIGSTOP / SIGCONT are more relevant to terminals, which don't align with the unikernel model. We should also be careful with expanding multiprocess support, as moving too far beyond our current baseline might inadvertently turn this into a complex, general-purpose OS.

[munseung1978]

Hi @michpappas ,

This is intended to be used in the native builds on Xen platform.

SIGCONT and SIGSTOP are used to start and stop ARINC 653 processes.

We are currently looking into the multi thread model and uk_sched_xxx functions to see if they can be used to start and stop the execution of ARINC653 process.

[matthew-l-weber]

Adding to @munseung1978 's note. No intentions of multi-processor/core support. This is single core, multi-threaded where we clone a single process into multiple (From Linux perspective, we get shared memory and IPC namespace) and then use the SIG* to manage state as @munseung1978 mentioned. Maybe we don't need to go through the clone complexity on Unikraft because there is no process isolation?