Re: Device probing and driver attach
On Fri, Nov 03, 2017 at 07:46:04PM +0100, Rocky Hotas wrote: > - In principle, if one built a custom kernel including *only* the drivers > needed by its current machine, would the boot time get significantly > reduced? Well, assuming any modernish bus with decent device enumeration functionality, the answer is pretty much "it doesn't matter". Most of the probe functions match things like bus/vendor IDs against a table. There are very few PCI devices that are more involved like checking the PCI config space (i.e. rtk vs re) and require many additional cycles. So even with a thousand probe functions run with one microsecond teach, we are talking about < 1 milli second per device. Given that the actual hardware configuration often contains delay loops, probing simply doesn't matter. > - When a BIOS does not perform this operation, is during the > autoconfiguration that device BARs are written by the OS? There are two different parts here: (1) Probing the size of a PCI BAR. This is done by the OS for general accounting. (2) Reserving and/or assigning space for devices. This is generally assumptions on x86 and many other platforms to be handled by the firmware, with some fallback code i.e. for hot plugging bridges. Joerg
Device probing and driver attach
Hi all! I hope this is appropriate to this list. 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". 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. - In principle, if one built a custom kernel including *only* the drivers needed by its current machine, would the boot time get significantly reduced? - When a BIOS does not perform this operation, is during the autoconfiguration that device BARs are written by the OS? - 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? Thanks to anyone who can answer to even just one... or half :) of the questions. Rocky
