Start here
Build for Kore
How programs are built for Kore, Micro Perceptron's capability kernel: the public pieces (libkore and the kore-abi contract), how they stack, and what stays closed.
What is public
Kore's kernel source is closed. Everything a program needs in order to be built for Kore is published in one repository, libkore:
- The libkore packages, under MPL-2.0:
kore-std(the Rust facade),kore-entry(an adapter for an ordinaryfn main()),kore-ffi(C headers and a Zig module),kore-lua(an embeddable Lua 5.5) andkore-wasi(a WASI 0.2 component host). - The native export under
native/:kore-abi, the kernel⇄user contract, and the runtime crates the facade is built on (kore-rt,kore-app,kore-dagfs,kore-driver,kore-ringand others). They are copied byte for byte from Kore at revisiond929d9a, with the source revision and file hashes recorded innative/provenance.json. They carry Micro Perceptron's own notice rather than an open-source license: you can read them and build against them.
The kernel itself, kernel images, the GPU and NPU drivers and the system services are not published. These docs describe only what the published contract states.
How the pieces stack
| Layer | What it is | Where |
|---|---|---|
| Your program | Rust, C, Zig, Lua, or a WASI component | Your repository |
| libkore | kore-std and the foreign-language surfaces | MicroPerceptron/libkore |
| Native runtime | Executor, session builder, SPMD, filesystem client, driver host, rings | libkore/native/crates |
| Contract | kore-abi: layouts and vocabularies, no behavior | libkore/native/crates/abi |
| Kernel | Kore | Closed |
A Rust program depends on kore-std and nothing below it. The procedural macros resolve the runtime through the facade, so a program never needs a direct dependency on kore-rt or kore-abi, even when it renames the facade.
The model in five rules
- A program holds capabilities, not permissions. Everything it can touch is a stamped record in its own capability arena, named by slot index. There is no root user and no ambient authority.
- It changes authority in sessions. A batch of
derive,revokeandrendezvousoperations is committed atomically in one trap into the kernel. - It moves data on rings. Bulk I/O runs on io_uring-shaped rings in memory it shares with its peers. A completion carries a slot index and a status, never a capability.
- It starts from what it was given. A new task reads a role-tagged handle table its founder wrote. What it was granted at founding is all it can reach; there are no environment strings and no name server.
- It reads the system without asking. Time, the boot chain's testimony and execution advice arrive on read-only pages, readable without a system call.
Status
libkore is 0.1.0-alpha.1. Its packages are not published to a registry: depend on a reviewed Git commit. kore-abi's wire layouts are frozen at ABI version 1 and change only additively, but libkore's own APIs make no stability promise yet.
Where to go next
- Getting started with libkore: toolchain, targets, a first program.
- The Kore ABI: how the contract is shaped and what it freezes.
- Kore: the kernel itself, for the architecture behind the contract.