Re: Device probing and driver attach

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Fri, 3 Nov 2017 19:46:04 +0100
    From:        "Rocky Hotas" <rockyhotas%post.com@localhost>
    Message-ID:  <trinity-9530aa11-fe48-4d21-a69a-cf19a766273e-1509734764878@3c-app-mailcom-lxa10>

  | - For each detected device, the probe function of *any* driver is called?

Depends upon what the system config says is possible.

  | - In principle, if one built a custom kernel including *only* the drivers
  | needed by its current machine, would the boot time get significantly
  | reduced?

Most times not enough faster to really notice.   However the kernel
can get a lot smaller.

  | - 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?

The system config (which is a combination of the kernel config file, and
the "files" files) specifies a tree of connectivity.   Some MD code starts
at the root (as what is the root is architecture specific) and then scans
whatever is the "primary" system bus for devices (which can be a combination
of simply knowing that some occur at a specific place, knowing that some
might occur, and looking to see if they are present, or doing some bus
specific operation to enumerate devices).   When found a device is perhaps
a new bus that needs to be handled recursively, or a device to attach, or
something that is not configured - the current kernel doesn't know what
to do with it - except ignore it and hope it doesn't do any harm.)

The code for all of this is spread all over the sys/dev tree, as well as
subr_autoconf.c (which as its name is meant to imply, is subroutines for
autoconfiguration  or if you prefer, the framework - but not anything
hardware or device specific.)

kre