Kore ABI
The io_uring data plane
Kore's I/O rings are byte-compatible with Linux io_uring, so liburing-style code ports by header swap. Completions name slots, never capabilities.
Source: uring.rsByte-compatible, not binary-compatible
Kore's I/O rings use Linux io_uring's exact byte layouts, so code written against liburing ports by swapping headers rather than by a rewrite. The structures are byte-identical on every Kore target, with their offsets pinned by assertion:
| Structure | Size | Notes |
|---|---|---|
IoUringSqe | 64 bytes | opcode, flags, ioprio, fd, off, addr, len, op flags, user_data, buf_index, personality, splice_fd_in, addr3 |
IoUringCqe | 16 bytes | user_data, res, flags |
IoSqringOffsets, IoCqringOffsets | 40 bytes each | Ring geometry |
IoUringParams | 120 bytes | Setup parameters |
The flag vocabularies (IoSqeFlags, IoSetupFlags, IoEnterFlags, IoFeatFlags, IoTimeoutFlags, IoCqeFlags) carry Linux's bit values. C unions are flattened to their primary member, which keeps the bytes identical, since kore-abi contains no unsafe code.
"Compatible" means layout, not binary. Kore doesn't accept a raw io_uring_setup(2) or io_uring_enter(2) binary: there are no file descriptors, no POSIX layer and no ring system calls. fd is an index into registered handles. Treat the setup and enter flags as source-compatibility vocabulary.
Rings are not kernel objects
A ring lives in a window of leased memory shared between two user-space peers: a client and a service, or a driver and its device queue. The kernel holds no ring object and offers no ring system call. When a producer has work for its peer, it rings a doorbell: a session rendezvous that sends a notice, which wakes the consumer if it is parked. Data never passes through the kernel.
A completion never carries a capability
Authority doesn't move on rings. A completion's res and flags carry a status and a slot index or byte count; there is no field wide enough to hold a capability record. Capabilities land in stamped arena slots and move only by rendezvous. So no asynchronous authority state can exist, and a ring peer can only operate on authority it already holds.
The same rule keeps host pointers off the ring. Where Linux puts a pointer in addr, Kore puts an inline value: a timeout carries its nanoseconds inline, and a storage request carries a target offset.
Op-codes
The vocabulary keeps Linux's values (NOP = 0 through MSG_RING = 40, then SOCKET, URING_CMD, SEND_ZC, READ_MULTISHOT and others up to LINUX_LAST = 65) and adds a Kore band from 0x80:
| Op-code | Value | Meaning |
|---|---|---|
SWAP_OUT | 0x80 | Write pages to swap |
SWAP_IN | 0x81 | Read pages back from swap |
PEER_COPY | 0x82 | Copy from a registered buffer into a peer's buffer |
DISCARD | 0x83 | Discard a storage range |
A vocabulary value is not a promise that every consumer implements it. In this export, kore-ring's builders produce NOP, READ_FIXED, WRITE_FIXED and PEER_COPY. The storage transport accepts READ_FIXED, WRITE_FIXED, FSYNC and DISCARD, and completes anything else as invalid.
Service rings
System services use the same split for their request paths. Each client and service pair shares one leased window holding a request ring and a reply ring; a channel beside it carries only doorbell notices and capability transfers. See service protocols.