Invoke Labels
Every typed operation on a kernel object in SaltyOS goes through a single syscall — SYS_INVOKE (#9) — dispatched on a 64-bit invoke label.
The label encodes which operation is being requested on which kind of capability.
This page enumerates every invoke label defined in lib/trona/uapi/consts/kernel.rs and pairs it with the safe Rust wrapper that substrate/invoke.rs exposes.
Anything listed here is what the kernel’s handle_invoke() in kernite/src/syscall/mod.rs switches on.
Adding a new invoke label means adding a constant here, a match arm in the kernel, and a wrapper function in substrate/invoke.rs — see Adding a Syscall or Invoke for the end-to-end procedure.
The invoke call shape
invoke::invoke() is the base entry point:
pub fn invoke(cap: Cap, label: u64, arg0: u64, arg1: u64, arg2: u64, arg3: u64) -> TronaResult
Every typed wrapper is a shim that picks a constant label and routes four scalar arguments into this function.
Results longer than two words (for example, the memory-map walk result) are returned in the per-thread IPC buffer and unpacked by helper functions such as vspace_walk_result_header() and vspace_walk_result_entry().
Under the hood, invoke() simply calls syscall(SYS_INVOKE, cap, label, arg0, arg1, arg2, arg3), so the kernel side sees a uniform seven-register call no matter which object type is being poked.
CNode (0x10–0x18)
Operations on capability nodes — copying, moving, and revoking caps inside a CNode.
| Label | Constant | Substrate wrapper |
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Nine labels, twelve Rust wrappers (some operations have a _depth variant for explicit CNode resolution depth).
Untyped (0x20)
Untyped memory is the source of every kernel object in SaltyOS — carving it via retype is how all kernel objects come into existence.
| Label | Constant | Substrate wrapper |
|---|---|---|
|
|
|
The new_type argument is one of the OBJ_* constants listed under Object types for retype below.
Untyped memory is the only kernel resource whose _retype operation creates new capability objects — everything else already-exists by the time userspace can invoke it.
SchedContext (0x30–0x31)
Scheduling contexts hold the budget and period for EDF-scheduled threads.
| Label | Constant | Substrate wrapper |
|---|---|---|
|
|
|
|
|
|
TCB (0x40–0x4F)
Thread Control Block operations — configuring a new thread, resuming/suspending it, binding notifications.
| Label | Constant | Substrate wrapper |
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Labels 0x44, 0x45, 0x47, 0x4A are reserved and not currently assigned.
VSpace (0x50–0x5F) plus MO mapping (0x97–0x9A)
VSpace operations map pages, demand-page regions, and fork ranges between address spaces.
The MO-mapping subset (labels 0x97–0x9A) is numerically adjacent to the MemoryObject labels below but semantically belongs to VSpace since the target object is a VSpace capability.
| Label | Constant | Substrate wrapper |
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The overlap between MO labels (0x90–0x97) and VSpace MO-mapping labels (0x97–0x9A) is intentional: 0x97 (MO_HAS_PAGE / VSPACE_MAP_MO) is dispatched based on the capability type, not the label alone.
The kernel looks up the invoked cap’s type first and picks the correct handler table.
IRQ (0x60–0x64)
IRQ control creates IRQ handler capabilities; IRQ handlers acknowledge interrupts and wire them to notifications.
| Label | Constant | Substrate wrapper |
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
DEVICE_UNTYPED_CREATE lives in the IRQ block numerically but operates on untyped memory — it is how drivers acquire direct-mapped untyped ranges for MMIO regions.
I/O Port (0x70–0x77)
x86-style I/O port access. On aarch64 the IoPort capability is still honored but the underlying handler emits no instructions — port caps on ARM64 systems resolve to an empty operation surface.
| Label | Constant | Substrate wrapper |
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
MemoryObject (0x90–0x97)
MemoryObject operations — the Fuchsia-inspired abstraction for anonymous backed memory that supports commit / decommit / clone / resize plus side-band read/write from the controlling process.
| Label | Constant | Substrate wrapper |
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
As noted above, label 0x97 is shared between MO_HAS_PAGE (when the target capability is a MemoryObject) and VSPACE_MAP_MO (when the target is a VSpace).
Label dispatch is always object-type first.
Object types for retype
UNTYPED_RETYPE needs to know what kind of object to carve out of the source untyped.
The new_type argument is one of:
| Code | Constant | Object |
|---|---|---|
1 |
|
Child untyped memory (for sub-allocating) |
2 |
|
Synchronous IPC endpoint |
3 |
|
Asynchronous notification object |
4 |
|
Thread control block |
5 |
|
Capability node |
6 |
|
Virtual address space root (top-level page table) |
7 |
|
A physical frame backing a user-space page |
8 |
|
IRQ handler capability |
9 |
|
I/O port range capability |
10 |
|
Scheduling context (budget + period) |
11 |
|
MemoryObject |
Page mapping flags
VSPACE_MAP, VSPACE_PROTECT, VSPACE_MAP_DEMAND, and their range variants all take a flags: u64 whose bits are:
| Bit | Constant | Effect |
|---|---|---|
0 |
|
Page is writable (PTE W bit) |
1 |
|
Userspace-accessible (PTE U bit) |
2 |
|
Instruction fetches allowed (clear PTE NX) |
3 |
|
Uncached mapping — used for MMIO |
4 |
|
Write-through caching |
5 |
|
Copy-on-write — triggers |
Total count
Across all object types, the invoke.rs module exposes 75 public wrapper functions around approximately 60 distinct invoke labels (some labels, notably VSPACE_MAP and CNODE_COPY, have both an "implicit depth" and a _depth explicit variant sharing the same label).
Label numbering is deliberately sparse so that future additions within an object-type group do not require renumbering.
Related pages
-
Syscall ABI —
SYS_INVOKEis one of the 28 syscalls. -
Capability Invocation — the substrate module that implements every wrapper listed here.
-
Error Codes — the error space every invoke can return.
-
kernite: Capabilities — the kernel side of the capability system.