Re: Device probing and driver attach

[Mouse <mouse%Rodents-Montreal.ORG@localhost>]

> 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		mouse%rodents-montreal.org@localhost
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B