August 2nd, 2024

Towards userspaceification of POSIX – part I: signal handling and IO

Redox OS has received a NGI Zero grant to improve POSIX signal handling and process management. Enhancements include userspace implementation, increased RedoxFS performance, and a more stable API for better functionality.

Read original articleLink Icon
Towards userspaceification of POSIX – part I: signal handling and IO

Redox OS has received a NGI Zero grant to enhance its POSIX signal handling and process management, focusing on userspace implementation. The primary developer, Jacob Lorentzon, has been preparing the kernel for new inter-process communication (IPC) changes and has begun replacing the existing signal implementation with a userspace-based approach. This transition aims to maintain current support levels while improving performance. Recent updates to the Redox kernel have led to a 63% increase in RedoxFS copy performance due to an improved scheme packet format and the introduction of new syscalls, SYS_PREAD2 and SYS_PWRITE2, which allow for more efficient data handling.

The project also addresses limitations in the existing signal handling, which lacked support for several key features. The migration from redox_syscall to libredox is nearly complete, allowing for a more stable API that facilitates userspace functionality. The proposed userspace signal handling will utilize shared atomic memory to optimize signal delivery and management, aiming to reduce syscall overhead. Future work includes implementing additional signal features and a userspace process manager to enhance POSIX compliance and sandboxing capabilities. The project is on track to achieve significant milestones by the end of summer, with ongoing improvements to kernel performance and functionality.

Link Icon 6 comments
By @mananaysiempre - 9 months
> POSIX allows file descriptors to be shared by an arbitrary number of processes, after e.g. forks or SCM_RIGHTS transfers (even though this use case is most likely very rare, so it’s not entirely impossible for this state to be moved to userspace).

Normally it’s rare, except shell functionality crucially depends on it[1].

The way to think about this, IMO, is that while a disk file is more or less random-access, when you open it unavoidably turns into strange hybrid of a random-access byte array and a (seekable) byte stream (classically, the “file description”), and that is what the resulting fd and any of its copies point at. Seekable streams made some sense in the age of tape drives, but nowadays it seems to me that random-access files and non-seekable streams have enough of a gulf between them that forcing both to appear like the same kind of object is more confusing than helpful.

(I don’t know what my ideal world would look like, given I still like to direct streams from/to files. I still dislike the “file description” business rather strongly.)

[1] https://utcc.utoronto.ca/~cks/space/blog/unix/DupSharedOffse...

By @tom_ - 9 months
Those who understand Unix are condemned to reproduce it exactly.
By @Animats - 9 months
Why emulate POSIX signal semantics? Those are a holdover from the single-thread UNIX era. Events should be delivered by threads or async calls. Signals should be reserved for exceptions, things you don't return to, like segfaults.
By @tbrownaw - 9 months
Would shared pipes not have approximately the same issue wrt file positions being shared state? A process group (cron job, systemd service) sharing a pipe for error output is probably a bit more common than directly having an on-disk file.
By @up2isomorphism - 9 months
This is very typical rust project. Trying to change the old world while tightly following the old world in a very unimaginative way.

Maybe too much memory safety is bad for creativity?