| Filename | Latest commit message | Latest commit date |
|---|---|---|
24f79194ab
docs/plan/hybrid.md mechanisms 2 and 4: MMIO and DMA to a process.
A process can enumerate the bus, claim a device exclusively, map its BARs and
get memory the device can be pointed at. Proven end to end against an e1000e
-- the exact device class we cannot drive and would want a foreign driver for:
device 7: 8086:10d3 (network)
claimed
BAR0 at 0x81060000, 128 KB
regs[0..3] = 0x00140261 0x00000000 0x00080283 0x00000000
MMIO reaches the device
DMA 8 KB at virtual 0x40001000, physical 0x3f8eb000
Those are the e1000e's CTRL and STATUS with full-duplex and link-up set, which
is how you tell a real mapping from one reading 0xFFFFFFFF off an unmapped
address. Claiming a device the kernel drives is refused -- two writers of one
register set looks like hardware that has started lying -- and everything a
process held is released when it exits, because a driver that crashed must not
keep its hardware away from its replacement.
mmap's offset is the BAR's physical address, checked against the BARs of
devices *this process has claimed*. Without that check the device is /dev/mem
with extra steps and a process could map the kernel's own memory. Mappings are
write-through: a cached write to a doorbell arrives whenever the cache feels
like it, which from a driver's side is indistinguishable from hardware that
ignores you.
The interface is about PCI devices, not about any driver model, and its first
users will be SchOS's own drivers when virtio-gpu is evicted. That ordering is
the design rather than an accident: an interface whose first consumers are
native drivers is a general mechanism something foreign can use later, instead
of a hole shaped like something foreign.
Also: PROT_* and MAP_* moved to include/posix.h. They were defined only in
sys_mem.c, so cmd/fbinfo carried a private copy and this wanted a third --
two copies of a number the kernel compares against, where a mismatch shows up
as a mapping with the wrong permissions rather than an error.
No IOMMU, so this isolates a driver against its own bugs and not against its
own DMA. The plan says so at length and it is still true.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VQ7Qx8E1q1M1bbCq8QLHS2
|
||
| .. | ||
| 1.0.md | ||
| foundations.md | ||
| hybrid.md | ||
| init.md | ||
| README.md | ||
| roadmap.md | ||
| schapi.md | ||
| wayland.md | ||
What happens next
Everything in this directory is unbuilt. When a piece of it is finished it leaves — deleted from here, rewritten as a description in ../architecture/. See the rule.
Read 1.0.md first.
It draws a finish line and puts most of the work below on the far side of it. Anything not named there is not being worked on, and the documents in this directory describe more than 1.0 contains.
The three current decisions
Taken together, because they turn out to need the same foundation.
| wayland.md | The GUI stack becomes Wayland. SchWM and SchDE are deleted; Schcom survives and changes its wire format. |
| hybrid.md | The kernel becomes hybrid — drivers move out into userspace processes, starting with the GPU. |
| init.md | PID 1 stops being a process and becomes a role the kernel guarantees is filled. |
And the one they all wait on:
| foundations.md | Descriptor passing, shared memory, sockets in the filesystem. The critical path. |
And the one that says which parts of the above are actually being worked on:
| 1.0.md | The finish line. Four gates, and everything else explicitly deferred. |
Two longer-horizon documents sit behind these: schapi.md, the API layering and the compatibility promise, and roadmap.md, which holds everything still open that is not one of the three above.
The order
Set by 1.0.md, which is the authority. In short:
0. Fix what is already wrong — first
Not a document of its own; it is Gate 0 of 1.0.md, assembled from the What it does not do sections in ../architecture/.
Before any new capability, and the reason is the one that put
netdev_selftest() before the TCP/IP stack: a compositor built on a kernel with
an unexplained hang and a socket layer that reports success for things it did not
do will fail in ways indistinguishable from its own bugs.
1. foundations.md — the critical path
Both the Wayland work and the hybrid work stop here. Descriptor passing and shared memory are the substrate for handing a buffer to a compositor and for handing a device to a driver process. Doing it once for both is the entire reason these are one plan rather than three.
2. init.md — before the desktop, not after
A compositor being brought up for the first time crashes constantly, and something that restarts it and says why is worth far more during that work than at the end of it.
3. wayland.md — with the GPU driver still in the kernel
W1–W3 and a terminal. W4 and W5 are post-1.0.
4. hybrid.md — after 1.0
Deliberately last: designing a userspace driver interface with no driver consuming it produces an interface that is wrong in ways nobody can see. The compositor is the demanding consumer that makes the interface judgeable, so it has to exist first.
In one sentence
Fix what is broken, build the descriptor-passing and shared-memory substrate, make init survivable, put a terminal on the screen — and only then use the compositor as the pressure that shapes the userspace driver interface.
What this plan does not address
Stated here so it is not mistaken for covered:
- No IOMMU, so the hybrid work isolates against bugs and not against a hostile driver.
- No page cache, so
foundations.mddelivers amemfdand not a general answer to shared file mappings. The general answer is still owed. - No dynamic linking, so no Mesa, no accelerated clients, and no third party
shipping a
.sofor anything. - A new compatibility surface between PID 1 and PID 2, created by a plan whose own schapi.md §3 spends a section warning about those.
- The three open networking items —
getsockname, routing, and interrupt-driven receive — are untouched by any of this and still open. They are in roadmap.md.