Driver matching

A kernel carries many drivers and meets many devices, and something has to decide which driver serves which device. The kernel cannot let each driver poke at every device to see whether it recognizes it, because a register that one chip uses for its status may start a command on another. So each driver declares in advance what it serves, as a table of matches: each entry names identity fields that the bus reports for a device, such as a PCI vendor and device id or class bytes, a USB interface class, or a compatible string from the firmware's description (buses). When a device appears, the kernel compares its identity with every table, and only the drivers with a fitting entry are offered it, one at a time, in the probe: the driver's chance to look at the hardware and either take it or decline.

Several drivers often fit the same device. A generic driver matches a whole class, such as every xHCI controller, while another matches the exact device id of a chip it knows better, and a driver a kernel author writes may match the same ids as one the kernel already ships. A kernel settles this with an order of preference. A more specific match comes before a more general one, because a driver that names the exact chip knows more about it than one that names its class. An explicit rank lets a driver step ahead of the others whatever its match, which is how a replacement wins over a shipped driver. A last key breaks the ties that remain. The first candidate whose probe accepts keeps the device, and a decline passes it to the next.

The trap is a tie broken by accident. If the last key is load order, hash order, or the order in which files happened to be compiled, the driver that binds a device can change when an unrelated driver is added or a file is renamed, and two builds of the same sources can behave differently. The last key has to be deterministic, and visible to someone reading why a device went to the driver it did. A decline must also leave the device as the next candidate expects it, since a probe that turned something on before declining hands the next driver a device in a state it did not choose.

In the driver kit, a driver's Matches is a list of DeviceMatch, each with a Specificity, the number of identity fields it checks. The candidates for a node are ordered by Priority (highest first), then by the specificity of their best match (highest first), then by manifest position (earliest first), and the first ProbeResult.Bound keeps the node. Every shipped driver leaves Priority at 0, so a replacement only needs a higher one. The manifest position is fixed at build time: the kernel's own drivers come first, ordered by file path and then by position in the file, followed by those of referenced assemblies, ordered by assembly name and then by full type name. The boot log lists each node's candidates with their prio and spec, and the kit releases whatever a declining probe acquired before it offers the node to the next candidate. See Identity and matches and How drivers are found.