Skip to content

add basic support of the system calls 'fork' and 'spawn_process'#970

Open
stlankes wants to merge 10 commits into
hermit-os:mainfrom
stlankes:fork
Open

add basic support of the system calls 'fork' and 'spawn_process'#970
stlankes wants to merge 10 commits into
hermit-os:mainfrom
stlankes:fork

Conversation

@stlankes
Copy link
Copy Markdown
Contributor

@stlankes stlankes commented Apr 8, 2026

In the long term, Hermit will also be usable as a monolithic OS. To prepare for this, an example of calling the system calls fork and spawn_process are being integrated. In the case of a unikernel, the fork call will return an error (ENOSYS).

@stlankes stlankes force-pushed the fork branch 2 times, most recently from 3fcf25e to 10fc90a Compare April 8, 2026 09:29
@stlankes stlankes changed the title add basic support of the system call 'fork' add basic support of the system calls 'fork' and 'spawn_process' Apr 10, 2026
stlankes added 6 commits May 3, 2026 11:07
In the long term, Hermit will also be usable as a monolithic OS.
To prepare for this, an example of calling the fork system call
is being integrated. In the case of a unikernel, the fork call
will return an error (ENOSYS).
Add the system call `spawn_process`, which creates a new process
from the executable file.
In the long term, Hermit will also be usable as a monolithic OS.
To prepare for this, an example of calling the fork system call
is being integrated. In the case of a unikernel, the fork call
will return an error (ENOSYS).
Replace all `-22` placeholders in the user-side syscall layer
with real `syscall!` invocations and extend `SyscallNo` with the
matching numbers (18–53) for spawn/join, file metadata, condvars,
task blocking and the socket API.
- extend the fork example to test the system call `exec`
Mirrors hermit/src/syscall/x86_64.rs for the aarch64 target so that
common-os user-space binaries can issue syscalls into the kernel.

Convention follows the Linux-like AArch64 SVC ABI:
  - svc #0           triggers the exception
  - syscall number   in x8 (input only)
  - arguments        in x0..x5 (up to six, like the existing macro)
  - return value     in x0 (`inlateout` for syscall1+, plain `lateout`
                            for syscall0)
  - PSTATE.NZCV is preserved across the SVC, so options(preserves_flags)
    is sound

The macro and the syscall0..syscall6 helper signatures match the x86_64
side verbatim, so the rest of the crate (sys_open, sys_read, sys_write,
sys_fork, sys_waitpid, …) compiles unchanged on aarch64.
@stlankes stlankes force-pushed the fork branch 3 times, most recently from dfdd348 to 0377355 Compare May 3, 2026 09:53
+ revert obsolete changes
Wires up the sys_mmap user-space stub (hermit_abi PROT_* flags,
plumbing in syscall/mod.rs and Cargo.toml) and switches the Talck-
based user heap from a 64 KiB static buffer to an mmap-backed heap
that can grow on demand:
- the first sys_malloc reserves an initial MIN_SIZE region via
  sys_mmap (anonymous, demand-paged), and HEAP_END tracks its
  current upper bound;
- a later allocation that exceeds the existing heap extends the
  same VMA via sys_mmap(extend_size, …, &mut heap_end) and tells
  the allocator about the new region with ALLOC.extend(…).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants