Device Manager and Driver Diagnostics

What is it?

A Device Manager answers "what hardware is in this machine, which driver owns it, and is it healthy?", as a window for users and as commands and APIs for tools. Impossible OS does not have one yet. Nothing records the devices it finds, so there is no device registry for a window, an lspci command or the SetupDi API to read. All ten sections of this roadmap are open; this page explains where the information lives today.

How does it work?

Today the information is scattered. The pieces a Device Manager would present already exist, but each is private to the code that produced it:

PCI devices. pci_scan() in pci.c logs every function it finds with a short class name and a count, then keeps nothing. A driver that wants its device calls pci_find_device(), which walks the bus again. See PCI, Plug and Play and Resource Manager.
Interrupts. irq.h keeps a count per vector (irq_get_counts()) and a name per handler (irq_get_name()), but no time spent and no rate, and nothing publishes them.
USB devices. The xHCI driver keeps its own table of attached devices, reachable through xhci_get_device() in xhci_dev.h; it is shaped for boot storage and input, not for a device tree.
Driver state. Each driver logs its own success or failure at boot; there is no shared health record.

The planned design. The roadmap turns this into one pipeline: the PCI scan fills a registry, an embedded copy of the PCI ID database turns vendor and device numbers into names, the interrupt layer adds live counts and rates, and each driver reports its health. Everything else reads from that one place.

flowchart LR
    S[PCI scan] --> R[(Device registry)]
    U[USB tree] --> R
    N[PCI ID names] --> R
    I[IRQ counts and rates] --> R
    H[Driver health] --> R
    R --> G[Device Manager window]
    R --> C[lspci, lsusb]
    R --> F["sys files: devices, interrupts"]
    R --> W[SetupDi API]

What are its interfaces?

Interface	Status
`pci_scan()`, `pci_find_device()`	Shipped; log and look up only (`pci.h`)
`irq_get_counts()`, `irq_get_name()`	Shipped per-vector counts and names (`irq.h`)
`xhci_get_device()`	Shipped USB device table (`xhci_dev.h`)
Device registry, `lspci`, `lsusb`, `/sys/devices`, `SetupDiGetClassDevs()`	Planned, not present

How do I use it?

Until the registry exists, the boot serial log is the device list: search it for the pci lines from the scan and for each driver's own init line. The machine matrix in Machine Matrix records which devices each test machine exposes.

What is not implemented yet?

A PCI device registry that the scan fills and drivers bind to (PCI Device Registry).
Device names from an embedded PCI ID database (Embedded PCI ID Database).
Live interrupt counters with rates (Live Interrupt Counter).
A driver health registry (Driver Health Registry).
/sys/devices and /sys/interrupts files (VFS Files).
lspci and lsusb shell commands (Shell Commands).
The Device Manager window (Device Manager GUI).
USB devices in the tree (USB Device Tree Integration).
The SetupDi Win32 API (Win32 API).
Driver unload and reload (Driver Unload / Reload).

How does it compare with Windows 11 and Linux?

Windows 11 keeps a PnP device tree, exposes it through SetupAPI and WMI and shows it in the devmgmt.msc snap-in, and reads live interrupt counters through Perfmon and NtQuerySystemInformation, but has no inbox lspci and its Device Manager shows no interrupt rates. Linux exposes devices in sysfs, interrupt counts in /proc/interrupts and names through pci.ids, with lspci and lsusb, but no built-in graphical Device Manager. Impossible OS has none of these yet. The roadmap aims for both: a native Device Manager window that refreshes interrupt rates and shows health badges live, plus Linux-style command-line tools and the Windows SetupDi API.