Multiboot ELF entry
boot.S is a spec-compliant Multiboot entry point. GRUB, QEMU, or any Multiboot loader hands the ELF a stack and an instruction pointer — no bootloader of our own to maintain.
// features
Everything in the binary, nothing beneath it.
cllm is a single 32-bit Multiboot ELF that boots on QEMU or bare-metal x86 and serves HTTP. These are the capabilities that ship today — grouped by the layer they live in — followed by an honest list of what is still on the roadmap.
Kernel
A Multiboot unikernel, not a container
Ring-0 everything
There is no kernel/userspace split, no syscall trap, and no scheduler. kernel.c runs the main loop in ring 0 and never context-switches to an unrelated process.
4 MB static heap arena
memory.c manages a statically-allocated 4 MB arena with malloc/free. No virtual memory manager, no page faults, no allocator surprises under load.
Custom libc subset
string.c ships only the libc we call — snprintf, memcpy, memset, strncmp — so there is no external C library to audit or link against.
Network
A NIC-to-HTTP path you can read end to end
PCI bus enumeration
network.c walks the PCI configuration space, finds the Intel e1000 device (8086:100e), and claims it — no ACPI, no device tree, no probe framework.
Intel e1000 driver
A from-scratch e1000 driver brings up the descriptor rings and moves raw Ethernet frames. The driver is a few hundred lines you can hold in your head.
Minimal IPv4 + TCP
Just enough of the stack to carry HTTP/1.1: IPv4, TCP, and the framing that the request router needs. No socket API, no BSD compatibility layer.
HTTP/1.1 server in-kernel
http.c parses requests and api.c routes them. The HTTP server is the packet-processing loop; there is no daemon sitting on top of an OS.
API
A llama.cpp-shaped surface your clients already speak
v1 completions & chat
POST /v1/completions and /v1/chat/completions match the llama.cpp request/response shape, so existing clients and SDKs point at cllm without code changes.
Embeddings & models
POST /v1/embeddings and GET /v1/models round out the OpenAI-flavoured surface that tooling expects to find.
Tokenize / detokenize
POST /tokenize and /detokenize expose the tokenizer directly for clients that manage their own prompt budgets.
Handler seam for the engine
llm.c is the interface where the llama.cpp inference path plugs in. The routes parse and dispatch today; inference returns a stub until that engine lands.
Operate
Boots fast, ships small, debugs cleanly
One-command boot
make run builds a release kernel and boots it in QEMU with serial on stdio. First serial line appears in well under a second.
GDB-attached debugging
make run-debug builds with symbols and pauses QEMU on :1234. target remote :1234 in GDB and step through ring-0 code directly.
Headless or VGA
make run is serial-on-stdio for CI and headless boots; make run-vga opens a VGA window for interactive inspection.
Single-ELF deploy
The deployment unit is one Multiboot ELF. No base image, no init system, no package manager, no userspace to patch.
// not yet — we do not overstate
What cllm cannot do today.
The scaffolding — kernel, drivers, network, HTTP — ships now. The inference engine and the items below are roadmap. Treat cllm as a working substrate the engine will land on.
- llama.cpp inference engine integrated into the kernel
- GPU / CUDA passthrough (design analysis only today)
- Streaming token generation
- TLS / HTTP/2
- Multi-threaded request handling
- Architectures beyond i386 (x86_64, ARM64, RISC-V are future work)