bus enumeration

Some hardware can introduce itself. When you plug a USB stick in, the system figures out what it is, who made it, and what driver it needs — all on its own. Bus enumeration is that process of discovery: the kernel walks a bus, asks each connected device 'who are you?', and each device answers with identifying numbers, so the kernel can match it to a driver and bring it to life. This is the opposite of the device tree, which is needed precisely when hardware CANNOT introduce itself.

Concretely, a discoverable bus has a standard way to query devices. On PCI, every device exposes a configuration space — a small set of registers the kernel can read at known offsets to get its vendor ID, device ID, class, and the addresses of its register regions (its BARs, base address registers). The PCI core scans all bus/device/function slots, reads each config space, and builds a list of present devices. On USB, when a device is plugged in, the host controller detects it, assigns it an address, and reads its descriptors (vendor, product, class, endpoints). In both cases the result is the same: a (vendor, device) identity that the driver model matches against each driver's table of supported IDs, then calls the winning driver's probe.

Bus enumeration matters because it is what makes plug-and-play work: you do not edit a config file when you attach a webcam, the bus discovers it and the right driver loads. The honest contrast to hold onto: enumeration works only for buses designed to be self-describing (PCI, USB, Thunderbolt). Fixed, soldered-on hardware with no discovery mechanism — common in embedded systems — cannot be enumerated and must be described out-of-band by a device tree or ACPI. Enumeration finds what is there; it does not invent identities, so a device with a misreported ID matches the wrong driver or none.