Lyx OS – Treibermodell: was unterstützt wird und wie

Diese Seite beantwortet zwei Fragen: welche Controller, Busse und Geräteklassen Lyx OS heute bedient — und womit man einen eigenen Treiber schreibt.

→ Lyx OS · Architektur · Geräte-Verzeichnis · lsdrv · lspci · XHCI-Treiber · Syscall-ABI

Tier-0 heißt nicht „fest verdrahtet„: Die Treiber tragen sich in eine Tabelle ein (kernel/drv.lyx), statt sich über if-Ketten in disk.lyx, vfs.lyx und kernel.lyx zu verteilen. Ein neuer Blocktreiber ist damit ein Registrierungsaufruf, keine Änderung an drei Stellen.

Die Zuordnung läuft über eine Frage an den Treiber — „gehört dir diese Gerätenummer?“ — statt über fest verdrahtete Nummernbereiche. Welche Geräte eine Maschine hat und in welcher Reihenfolge, darf den Ablauf nicht bestimmen.

Acht Plattenplätze (0–7) für physische Laufwerke, vier RAM-Disks, ein USB-Speicher. Die Registrierung als Blocktreiber erfolgt für ata, ramdisk und usb; NVMe und virtio-blk hängen im Plattenverwalter am Bus-Feld.

Darüber liegt kernel/nic.lyx als eine Schnittstelle: der Netzstapel (net.lyx) kennt keine Karte mehr. Vorher rief er E1000Send/E1000Recv unmittelbar auf — damit hatte Lyx OS in VirtualBox schlicht kein Netz.

Der Grund für „bei Bedarf„ steht im Manifest: AC97 und HDA fassen beim Hochfahren PCI, Anschlüsse und DMA an — und genau das hat auf echter Hardware Eingabe und Platte gestört. Ins Geräte-Verzeichnis kommt deshalb nur, was steckt; die Auswahl fällt beim ersten Ton.

Jeder Treiber hat eine Datei unter /lib/drivers (im Baum: drivers/*.mf). Sie sagt, wofür er zuständig ist und wann er geladen wird:

# Manifest: USB-Controller (xHCI)
name     xhci
treiber  eingebaut
laden    sofort
abi      1
match    PCI\CC_0C0330

Geprüft wird vom genauesten zum allgemeinsten; der erste Treffer gewinnt. So kommt ein auf das Modell zugeschnittener Treiber vor einem, der nur die Chipfamilie kennt:

lsdrv hält die Manifeste gegen die tatsächlich gefundenen Geräte und zeigt IST gegen SOLL; lyxdevd bindet danach wirklich.

Ein Ring-3-Treiber braucht genau zwei Dinge, um überhaupt anzufangen: seinen MMIO-Bereich im eigenen Adressraum und Zugriff auf die PCI-Konfiguration. Alles Weitere kommt in Stufen dazu:

Der Treiber bekommt nie eine rohe physische Adresse. Er sagt „DMA in meinen Puffer der Größe N“, bekommt eine Kennung und den Puffer in seinen Adressraum abgebildet — die Adresse ins Geräteregister trägt der Kernel ein, nach Bereichsprüfung. Damit ist die naheliegendste Fußangel („beliebiger physischer Schreibzugriff„) schon in Fassung 1 weg.

Bis 2026-08 fragten die Treiber ihre Geräte ab: USB-HID mit 100 Hz aus dem vsync-Pfad, der Netzempfang in jeder Warteschleife. Das kostet Rechenzeit, meldet spät — und hängt daran, dass jemand die Abfrage überhaupt ruft. Genau daran war USB-HID im Desktop schon einmal tot, weil vsync_wait niemand mehr rief.

Die Verteilung selbst steht in kernel/irq.lyx (Vektor → Lyx-Handler, Rahmen drv_irq_common für 0x50–0x5F mit LAPIC-EOI und drv_pic_common für 32–47 mit PIC-EOI) — siehe Kernel-Interna.

• MsiBindVector(bdf, vektor) ergänzt msi.lyx um eine Bindung mit freier Vektorwahl. MsiBind vergibt fest 0x60+notify_id — gedacht für Ring-3-Treiber; ein Treiber im Kernel will seinen eigenen Vektor aus der Verteilung.
• XhciIrqAttach(idx, vektor) trägt erst den Handler ein, bindet dann MSI/MSI-X und schaltet zuletzt den Interrupter scharf. Andersherum könnte der erste Interrupt eintreffen, bevor jemand zuständig ist. QEMU (–usbhid): Vektor 0x50 (MSI-X).
• Den Ring einmal leeren, nachdem scharf geschaltet wurde. Ein Interrupt entsteht beim Übergang auf „es liegt etwas an“ — lag beim Umschalten schon ein Ereignis im Ring, kommt danach nie einer. Derselbe Aufruf holt zugleich die ausstehenden Transfers nach, denn das Nachladen (Doorbell) passiert in derselben Schleife wie das Abarbeiten.
• Kein fristbasierter Rückfall. „Kam in N Durchläufen kein Interrupt, dann zurück zur Abfrage„ schaltete immer zurück: im Leerlauf ist „kein Interrupt“ der Normalfall — die Frist maß nicht den Fehler, sondern die Ruhe. Stattdessen XhciTick(): ohne Interruptbetrieb die alte Abfrage, mit Interrupt nur noch ~1×/s als Sicherheitsnetz, damit ein verlorenes Ereignis nicht dauerhaft hängen bleibt.

• Befund zuerst: der e1000 maskierte seine Interrupts nicht, sondern schaltete sie ein. Der Code schrieb 0xFFFFFFFF nach 0x00D0 mit dem Kommentar „IMC: alle Interrupts maskieren„ — beim 82540EM ist 0x00D0 aber IMS (Maske setzen), IMC liegt auf 0x00D8. Folgenlos, solange kein Handler gebunden war, an drei Stellen korrigiert.
• NicIrqAttach(vektor) richtet den Empfangs-Interrupt ein, mit zwei Wegen: MSI bevorzugt (kein Routing, keine geteilte Leitung) und INTx als Rückfall — QEMUs 82540EM hat gar keine MSI-Capability, meldet sich aber über eine klassische Leitung (Konfigurationsraum 0x3C); Vektor = 32 + Leitung, eingehängt über op117. Belegt in QEMU: Leitung 11 → Vektor 43.
• Der Handler verarbeitet nichts — er quittiert (ICR lesen, read-to-clear) und zählt. Das Auslesen bleibt in den Warteschleifen, die den Inhalt ohnehin deuten müssen; den Protokollstapel in den Interruptkontext zu ziehen wäre viel Risiko für wenig Gewinn.
• Freigeschaltet werden nur die Empfangsursachen (RXT0, RXO). Sendequittungen und Verbindungswechsel kosten je einen Austritt aus dem Gastmodus, ohne gebraucht zu werden.

Der geplante Umbau der AHCI/NVMe-Fertigmeldung auf Interrupt unterblieb — die Messung davor fiel eindeutig aus: disk Wartezeit bis hier: 0 ms in 0 Zugriffen. Der QEMU-Boot liest überhaupt nicht von der Platte; Kernel, Initrd, Schriften und Hintergrund kommen aus der Initrd im Arbeitsspeicher.

Auch bei Zugriffen wäre der Gewinn klein: NVMe wartet in cq_wait auf ein Phase-Bit in der per DMA gefüllten Completion Queue (Rechenzeit, aber keine teuren Gerätezugriffe), AHCI pollt PxCI per MMIO aus dem Bootloader-Assembler. Und der ganze Pfad (DiskRead → fat32 → vfs → Syscall) ist synchron: der Wartende kann nicht schlafen. Ein Interrupt, der eine Marke setzt, ersetzt die Warteschleife nicht, er ändert nur ihr Ziel. Der Gewinn entstünde erst mit asynchronem Disk-I/O.

Die Messung selbst bleibt (zwei TSC-Lesungen je Zugriff) und beantwortet die Frage künftig sofort — auch dort, wo tatsächlich von Platte gelesen wird. Ausgegeben wird sie nur, wenn es Zugriffe gab.

Der Kernel meldet den Stand beim Hochfahren: drv Sicherheitsmodus: AN — Geraetezugriff nur mit Manifest (LBF).

Letzte Aktualisierung: 2026-08-29 — Abschnitt 5 „Interrupts statt Abfragen“ ergänzt (WP-DRV-3, USB-HID über MSI-X, Netz-RX über INTx, e1000-Registerfehler, Disk-Messung); erhoben aus kernel/irq.lyx, kernel/acpi_pm.lyx, kernel/xhci.lyx und kernel/nic.lyx.

Vorherige Aktualisierung: 2026-08-27 — Seite neu angelegt; aus drivers/*.mf, kernel/drv.lyx, kernel/disk.lyx, kernel/nic.lyx, kernel/ring3.lyx (DRV-3…DRV-6) und kernel/xhci.lyx erhoben.