a1c965da1e
Sixty-five headers sat side by side in include/, so `#include "irq.h"` said nothing about where irq.h was or what it belonged to, and errno.h, stat.h and fcntl.h at the top shadowed the system's for any host tool built with -I./include. They are in folders now -- arch/ core/ fs/ dev/ gfx/ net/ uapi/ (and ldls/ for the Linux driver layer) -- and every include names the folder, as Linux's do: "core/proc.h". Done mechanically and checked the hard way: the kernel built from this tree disassembles identically to the one built from the tree before it. The full image boots, and userland is the same set of programs. Paths in docs and comments follow; docs/guides/layout.md has a table of what is where, and tools/fix-includes.py rewrites old-style includes from the folders in the tree, for code written before this. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01S1giNvrHTrPMPw7V6x1kQ4
2.4 KiB
| name | description | metadata | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|
| schunix-pci-drivers | PCI enumeration lives in kernel/dev/pci.c; drivers that find their own hardware go in kernel/drivers/ and are listed in registry.c |
|
kernel/dev/pci.c enumerates the PCI bus (added 2026-08-04), through the
old 0xCF8/0xCFC config mechanism — the one that works without first finding an
ACPI table. The scan recurses through bridges rather than sweeping all 256
buses flat, so it also knows what sits behind what.
BAR sizes are found by writing all ones and reading back the bits the device does not decode; the original value must be restored, since that briefly points a live device's decoder at the top of the address space. 64-bit BARs consume the following slot. Only header type 0 has six BARs — a bridge is type 1 with a completely different layout.
kernel/drivers/ is the folder for drivers that have to find their
hardware. Fixed-address legacy devices (console, keyboard, the IDE ports)
stay in kernel/dev/. To add one: write kernel/drivers/<name>.c exporting a
struct pci_driver, declare it in kernel/drivers/registry.c, add it to the
array there, and add the object to KERN_DRIVERS in the Makefile.
The registry is a plain array rather than the linker-section trick, on purpose: it keeps the list of what is in the kernel somewhere you can read. A driver silently dropped by the linker looks identical to one never written.
kernel/drivers/vga_pci.c is the first driver and the template. It draws
nothing — vga.c still owns the framebuffer — but it cross-checks the aperture
it finds on the bus against the address VBE reported. That disagreement is
exactly the symptom that would have surfaced first on hardware where the old
hardcoded 0xfd000000 was wrong. See schunix-framebuffer-device.
cat /proc/pci lists everything found, lspci-shaped, with the binding
driver in brackets ([-] when unclaimed). Under QEMU's default i440fx it
should show six devices; tools/bootcheck.ps1 asserts on the host bridge and
the IDE controller by ID, and on [vga] having bound.
inl/outl were added to include/arch/x86.h for this — config space is only
reachable in dwords, so pci_read16/pci_read8 shift and mask the containing
dword rather than doing a narrower bus cycle.