> When the OS is booted, it still doesn't know the devices that will be > present in the current machine and it doesn't then know what drivers > should be used. After the bootstrap, the system autoconfiguration is > performed: according to autoconf(9), "Autoconfiguration is the > process of matching hardware devices with an appropriate device > driver".
Yes...though I'd say, rather that autoconfig is performed _as part of_ bootstrap, not _after_ bootstrap. But that's just a question of where you draw the line that says what is or is not part of bootstrap. > Here follow some questions: > - For each detected device, the probe function of *any* driver is > called? It seems a cumbersome procedure, but boot time is not that > much long. "It depends." In some cases, the kernel will skip calling the driver because it can't possibly be right - as a simple example, you won't see ISA probe/match functions called for a USB device. Also, some buses don't permit detecting hardware in a driver-independent manner. On ISA, or Qbus, for example, there really isn't any way to say "there's a device at 0x123450" without calling on a driver that knows how to recognize that device. In contrast, Bluetooth and PCI (for example) do permit some degree of detection of a device's existence before knowing details about it. > - In principle, if one built a custom kernel including *only* the > drivers needed by its current machine, would the boot time get > significantly reduced? "Maybe." In my experience, this usually doesn't reduce boot time much, but I also usually don't cut out the worst of the time-wasters. It really depends on how far back you're willing to trim the driver set and exactly what devices remain. > - When a BIOS does not perform this operation, is during the > autoconfiguration that device BARs are written by the OS? Not all machines have a BIOS; a few don't even have anything very similar. And BARs are, as far as I know, a PCI-only thing; there are lots of other buses out there. As for PCI BARs in particular, I'm not entirely sure, but I _think_ that nobody but the MD startup code (BIOS or moral equivalent) is ever supposed to write BARs (except for the address-size detection dance, which writes them but immediately puts them back the way they were). I'm sure someone here who really knows PCI can confirm-or-refute that. > - autoconf(9) specifies that "The autoconfiguration framework itself > is implemented within the file sys/kern/subr_autoconf.c". I am not > that skilled with it: which is, in that file, the routine that > searches for new devices and calls driver probe functions? I don't think it's entirely in there. Individual bus implementations will contain (at least) the bus-specific portions of that; for example, walking PCI config space will be off somewhere under sys/dev/pci, while looking for Qbus devices will be elsewhere - sys/dev/qbus, I would guess. The different addressing mechanisms mean it has to be done fundamentally differently, too; Qbus has to walk all drivers instead of all devices, because there's no way to locate Qbus devices without the help of the possibly-relevant drivers. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML [email protected] / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
