nexoniarz/SchOS
nexoniarz/SchOS
Watch
1
0
Fork
You've already forked SchOS
 0
Code Issues Pull requests Projects Releases 1 Packages Wiki Activity Actions

hybrid: H4 withdrawn -- USB is not a peripheral

Browse source 
Not deferred and not blocked on the per-device ownership interface the last
commit described. Withdrawn, because the premise was wrong.

USB is the bus the peripherals arrive on. Nearly every machine has a port in
some form, down to a bad micro-B on a board with nothing else, and the ones
that have none are not made worse by the stack being there. That makes it
structurally the same kind of thing as PCI, and this plan has never proposed
evicting PCI.

The eviction rule already said so and was read too quickly: "anything
discovered at runtime ... goes out" is about the things USB discovers, not
about USB. The keyboard and the root disk that arrive over it are on the path
to a shell, and the stack that finds them is part of that path.

The obstacles recorded in the previous commit are real, but they are not the
reason. Even with a minimal in-kernel fallback written and a per-device
ownership interface designed, the good USB driver and the minimal one would be
the same driver -- and an eviction that leaves an identical copy behind has
moved nothing.

hybrid.md is now closed and leaves the register in docs/plan/1.0.md. What the
four mechanisms were built for next is the foreign driver host.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VQ7Qx8E1q1M1bbCq8QLHS2
This commit is contained in:
Nexoniarz 2026-09-14 01:45:58 +02:00
commit 907d0e6c8a
4 changed files with 5489 additions and 7 deletions
Download patch file Download diff file Expand all files Collapse all files

2
docs/plan/1.0.md
View file

@ -94,7 +94,7 @@ The galling ones. The work exists, is tested, and nothing uses it.
| | Where it stopped |
|---|---|
| **`foundations.md`** | Item 1 built. Items 2 (a shareable memory object), 3 (`AF_UNIX` in the filesystem namespace), 4 and 5 open. **Wayland stops at item 2.** |
| **`hybrid.md`** | All four mechanisms built. H1, H2 and H3 done — the driver can be killed and comes back, and the display mode can be changed from a process. **H4, the USB eviction, is the only one left and is much the largest thing on this register**: `xhci.c` plus a USB core and three class drivers, all of which are on the path to a shell on real hardware. |
| ~~**`hybrid.md`**~~ | **Closed.** All four mechanisms built; H1, H2 and H3 done. H4 — the USB eviction — is *withdrawn* rather than outstanding: USB is the bus peripherals arrive on, not a peripheral, and an eviction that has to leave an identical driver behind has moved nothing. See [hybrid.md](hybrid.md), "Decided: USB stays in the kernel". |
| **Schcom v0** | 715 lines that composite, over a wire format that is superseded. Frozen: it runs, nothing more is added, and it is kept only because it is the one thing in the tree that has ever put a client's pixels on screen. |
| **`debugger.md`** | D0 through D4 built and described in [../architecture/debugging.md](../architecture/debugging.md). Only the network transport is open — a userspace daemon bridging TCP to `/dev/dbg`, which is deliberately last. |

44
docs/plan/hybrid.md
View file

@ -157,8 +157,9 @@ re-fires for ever, drowning the e1000 that shares it. The fix is one line,
is that the storm detector built for history/kernel.md section 13 named the
line, the rate and the neighbour without anyone having to look.
**All four mechanisms now exist.** What remains on this plan is the second
eviction -- USB -- and then the foreign driver host.
**All four mechanisms now exist**, and with H3 done and H4 withdrawn, nothing
remains on this plan. What the mechanisms were built for next is the foreign
driver host -- [ldls.md](ldls.md).
### One thing the interface is deliberately not
@ -401,7 +402,7 @@ Four reasons it is the right one and not just the interesting one:
rather than to no screen.
- It directly serves the work that will actually be happening.
### Second: USB
### Second: USB — and why it turned out not to be
`xhci.c` is 1364 lines, self-contained, already spoken to through a bus
abstraction, and it is where third-party drivers will show up first. This is what
@ -445,8 +446,39 @@ same thing. Handing a process "the xHCI controller" gives it the keyboard too;
handing it "one USB device" is an interface `/dev/pci` does not have and that
this plan has not designed.
**H4 needs that interface designed before it needs code.** Recorded here rather
than discovered halfway through 2,550 lines.
#### Decided: USB stays in the kernel
**H4 is withdrawn.** Not deferred, not blocked on the interface above —
withdrawn, because the premise was wrong.
> **USB is not a peripheral.** It is the bus the peripherals arrive on.
Nearly every machine has a USB port in some form, down to a bad micro-B on a
board that has nothing else, and the ones that do not have one are not made
worse by the stack being present. That makes USB structurally the same kind of
thing as PCI, not the same kind of thing as a GPU — and this document has never
proposed evicting PCI.
Reading the eviction rule again with that in mind, it already said so:
> **Anything needed to reach a shell stays in. Anything discovered at runtime,
> replaceable, or plausibly written by someone else goes out.**
USB is how things are *discovered at runtime*, which is not the same as being
one of them. The keyboard and the root disk that arrive over it are on the path
to a shell, and the stack that finds them is part of that path.
The two obstacles in the section above are real and they are why the premise
got questioned, but they are not the reason for this decision. Even with a
minimal in-kernel fallback written and a per-device ownership interface
designed, the answer would be the same: the good USB driver and the minimal one
would be the same driver, and an eviction that leaves an identical copy behind
has moved nothing.
What the eviction was *for* — third-party drivers, written by someone else,
living outside the kernel — is a real goal and it survives this. It is simply
not a USB goal; it belongs to the foreign driver host, which is
[ldls.md](ldls.md).
### The rule that keeps the boot path honest
@ -466,7 +498,7 @@ start because the display driver is a process that needs a compositor.
| **H1** | A userspace virtio-gpu driver, publishing `display_ops` across the channel. Schcom talks to it and does not know the difference. | done, except that Schcom does not talk to it -- `cmd/vgpud` holds the device and draws its own frame |
| **H2** | Kill the driver process on purpose. The screen falls back to VBE, the driver restarts, the compositor reattaches. **This is the milestone that proves the whole idea**, and it is the one that cannot be skipped. | done, less the compositor -- see "The driver came back" |
| **H3** | A modeset API, which is the thing an out-of-kernel GPU driver makes affordable and an in-kernel one never got. | done -- see "A modeset, from a process" |
| **H4** | USB, same shape. | the one left, and much the largest |
| ~~**H4**~~ | ~~USB, same shape.~~ **Withdrawn** — USB is the bus peripherals arrive on, not a peripheral. See "Decided: USB stays in the kernel". | |
---