[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Device probing and driver attach
> 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
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 mouse%rodents-montreal.org@localhost
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Main Index |
Thread Index |