Ceylon Development Log — September 15, 2026: Locking the Baseline Before Moving Forward
A day spent proving the new low-level foundation: DMA and interrupt isolation, multicore FPU safety, runtime boundaries, and an integrated harness that learned to trust shared state instead of notification counts.
September 15 was one of those days where a lot of work happened without producing something flashy on the screen. That is not a complaint. For an operating system project, these are some of the most important days.
The focus was on getting Project Ceylon's current reference build into a state where we could confidently say: this is the known-good machine, and anything we change from here has to prove that it is at least as trustworthy. That baseline is now locked.
The last known-good build
Before beginning the next major low-level system update, I wanted a reproducible reference point. Not the last version that seemed to work. Not whatever happened to be in the build directory. A real baseline.
That meant capturing the exact source revision, system image, kernel image, dependency versions, test results and performance measurements associated with the current working system.
The reference build completed its regression suite successfully, including 407 workspace tests, 86 documentation and contract checks, RTC and time synchronization tests, software-emulated and hardware-assisted virtualization boot testing, and baseline IPC, notification, shared-memory and floating-point performance measurements.
That build is now the project's GOLDEN-PRE23 reference. It gives us something extremely valuable: a control group. From this point forward, a major platform change cannot simply say, "it boots." It has to answer a much harder question: is it actually better—or at least no worse—than the system we already know works?
Why I am being so conservative
The low-level platform underneath Ceylon is going through a fairly substantial upgrade. This affects process isolation, memory ownership, shared memory, device access, DMA isolation, interrupts, multicore execution, inter-process communication, floating-point and SIMD state, and runtime and linker behavior.
Those are not areas where I want to rely on optimism. A bug in a graphical application is irritating. A bug in the part of the system that decides which device is allowed to write to which physical memory is an entirely different class of problem.
The goal is to eventually take Ceylon from the virtual development machine to real x86-64 hardware. The more of these architectural assumptions we can prove now, the fewer surprises we should encounter when that transition begins.
DMA isolation passed
One of today's major validation areas involved device DMA. In simple terms, DMA allows hardware devices to access memory without asking the CPU to copy every byte. It is important for high-performance storage, networking, graphics and media processing—and it needs strict boundaries.
The test system defines separate, bounded DMA windows for multiple virtual devices and verifies that a device cannot wander outside the memory assigned to it. The validation included attempts below and above an allowed window, across its boundary, through unmapped holes, into memory owned by another device, and into memory belonging to another authority domain.
Those tests passed in both software-emulated and hardware-accelerated environments. That may not make for a glamorous screenshot, but for the kind of workstation Ceylon is intended to become, this is foundational.
Interrupt ownership found a real defect
The interrupt tests did exactly what good validation is supposed to do: they found something. A network device still had an interrupt assignment left over from an earlier configuration, even though that network path had evolved into a polling-based design.
The stale route was removed, the candidate was rebuilt, and the interrupt tests were repeated. The corrected build demonstrated proper interrupt ownership and no cross-delivery between unrelated components. That corrected build became the current upgrade candidate.
Multicore floating-point isolation
Another major test involved floating-point and SIMD state across multiple CPU cores. The validation exercised vector registers, traditional floating-point state, control registers and fault behavior while placing independent owners on separate processor cores.
The state remained isolated. One component could fault without exposing its floating-point state to the surviving component. That is important evidence that the upgraded low-level system is behaving the way Ceylon's architecture expects.
Runtime and shared-memory testing
The upgraded runtime was also put through tests covering IPC buffer placement, stack alignment, linker layout, thread-local storage, protected procedure calls, notifications, shared memory, runtime identity, fault-entry behavior and multicore operation.
Some of this work is specifically important because seemingly small changes to the underlying runtime can alter assumptions made by Rust, the linker or the system's memory layout. I'd rather expose those assumptions now.
Then came the integrated test
Individual tests are useful, but eventually all these pieces have to operate at the same time. So the next step was an integrated multicore workload combining many of the previously tested paths.
That test initially failed. Interestingly, the operating system itself was not the culprit. The validation harness was. We found synchronization problems in the test machinery, particularly around how completion notifications and shared-state bookkeeping interacted.
That resulted in an important design correction to the test framework: notifications are treated as doorbells, not counters. The actual truth lives in monotonically advancing shared state. A notification says, essentially, "something may have changed; go look." It does not attempt to encode exactly how many things changed.
By the end of the day's work, the corrected harness had progressed through increasing workloads, including the longer integrated test horizon.
Validation tools need validation too
One recurring theme in this phase is that test software deserves the same skepticism as production software. We've found several occasions where an apparent operating-system failure was actually a flaw in the test fixture itself.
That isn't wasted work. A test that cannot prove it would detect the thing it claims to detect is not very useful. The validation framework includes negative controls and deliberately incorrect states intended to demonstrate that failures really are observable.
Where Ceylon stands
The previous system remains the governing baseline. The upgraded system is still a candidate. That distinction is intentional. The new build does not become "the operating system" merely because it compiled, booted or completed a few demonstrations.
The remaining process includes integrated validation, regression reconciliation and performance comparison against the known-good baseline. Only after that evidence is complete will I consider replacing the current reference.
Why this matters later
Ceylon is being built in a virtual machine first, but the VM is not the destination. It is the laboratory. The eventual goal is real x86-64 hardware, with real storage controllers, real networking, real graphics hardware, real DMA and real timing behavior.
I want the virtual implementation to give us a tested architecture for those systems before we begin dealing with hardware-specific complications. Then moving to bare metal becomes a hardware-enablement problem instead of an architectural reinvention.
That is the theory, anyway. And September 15 moved us quite a bit closer to finding out whether it works.
— Mike
Originally published on The Weekend Report: https://theweekendersproject.com/report/ceylon-development-log-september-15-2026-locking-the-baseline