Roadmap and status

The kernel is built in phases, each one a layer the next one needs. The short checklist lives in the README; this page is the longer version, plus the link to where the work is actually tracked.

Phase	Subject	State
0	Development environment: cross-compiled i686-elf toolchain in a container	done
1	Boot via GRUB/Multiboot, VGA text output, serial logging	done
2	GDT and TSS (segmentation)	done
3	IDT, exceptions and hardware interrupts (timer, keyboard)	in progress
4	Memory management: physical allocator, paging, heap	planned
5	Multitasking	planned
6	Drivers and filesystem	planned

Phases 0 to 2 are closed, which here means more than "the code is written": each has self tests that run at every boot and interrogate the hardware, so a regression in a closed phase shows up as a failing check in the next boot rather than as a mystery three phases later.

What phase 3 already contains

• An IDT with all 256 gates installed. 48 vectors have an entry point behind them — the 32 the CPU reserves for its own exceptions, plus the 16 the PIC was remapped onto — and the other 208 are left not present on purpose, so an unexpected vector produces a fault with a message instead of a jump into whatever happened to be at address zero.

• One register-frame shape for every vector, exceptions with an error code and exceptions without alike, so the dispatcher and the dump do not need to know which kind they are looking at.

• A diagnosable death: an unhandled exception prints the vector with the mnemonic the Intel manual uses, every general-purpose register, eip, eflags, the error code and the segment registers, on every output channel, and then halts. No silent triple fault.

• The 8259A PIC pair remapped off the exception vectors onto vector 32 and up (vector 8 was #DF and 13 was #GP — before the remap a timer tick and a double fault were indistinguishable), with every line masked, the spurious IRQ 7 / IRQ 15 rule handled inside the acknowledge path, and the cascade line managed on its own.

• A machine-independent interrupt interface: generic code says "run this when that line fires", "not now", "done", and never sees an x86 frame.

• Self-test suites for the GDT, the PIC and the IDT, registered by the architecture at init and run at boot.

• A periodic timer: the 8254 channel 0 at 100 Hz on IRQ 0, with a 64-bit tick counter that a 32-bit machine can read without ever catching it half updated. Every boot proves the tick arrives; the rate itself was measured once against a real clock, 3900 ticks in 39.000 s.

What the phase still owes is the keyboard, plus the gaps already written down as issues — see the milestone.

Milestones

Issues are grouped by the phase that has to settle them. That is also how a security or debt issue gets a deadline: not "someday", but "before the phase that would make it exploitable".

Milestone	Scope
Phase 3 — Interrupts: IDT, exceptions and IRQs	What is left before the interrupt phase can be called closed: the #DF handler, the NMI gate with no handler behind it, a regression guard for the stub entry invariants.
Phase 4 — Memory management	The Multiboot memory map (received and currently ignored), validating it as outside input, a 64-bit physical address type before the allocator invents one, and the page-fault path.
Phase 5 — Multitasking	Everything that becomes real the moment there is more than one context and a ring 3: the per-task kernel stack in tss.esp0, the first iret frame, user segments that are still flat 0-4 GiB.
Phase 6 — Drivers and filesystem	Devices and storage. Open, nothing filed yet.
Backlog	Real but not phase-bound: a kprintf format bug, and generic code still reaching for x86 headers.

The full list, filterable by label, is in Issues.

Which build am I looking at

The kernel prints its own version in the boot banner, from include/version.h — one definition, so the number on screen is the number of the tree you built. Quote that line (and the commit you built) when you report anything; see Reporting issues.