LinuxCon: A tale of two bootcharts

Posted Aug 27, 2010 20:13 UTC (Fri) by BenHutchings (subscriber, #37955)
In reply to: LinuxCon: A tale of two bootcharts by Trelane
Parent article: LinuxCon: A tale of two bootcharts

It strikes me, however, that the basic problem *here* is finding out what hardware is present and not present.

I think you're confused about how hardware probing is done. Back in the 90s PCs would have a load of ISA devices that each had to be probed in their own way. Today almost every device is described by ACPI tables or the standard PCI or USB configuration mechanisms. The kernel uses these to find which devices are present and only invokes the drivers associated with them. It also sends events out to udev, which loads modules if needed. The 'probing' I refer to involves drivers checking which variant is present and then initialising it appropriately; drivers that you don't need will never be invoked. (There are exceptions, e.g. 8139cp and 8139too handle different devices with overlapping sets of device IDs. Normally they will both be loaded and may both probe the same device.)

This could be mitigated by means of a table of "known to be present" hardware information supplied to a bulk-loaded module set (something along the lines of putting all the .ko's into a single .ko with tables specifying that it's a bulk module and where everybody's at in it, as outlined above.)

That might be worth a try.

LinuxCon: A tale of two bootcharts

Posted Aug 27, 2010 20:21 UTC (Fri) by Trelane (subscriber, #56877) [Link]

I think you're confused about how hardware probing is done.

Oh, that's a virtual certainty. ;)

[excellent lesson here; thanks!]

The 'probing' I refer to involves drivers checking which variant is present and then initialising it appropriately; drivers that you don't need will never be invoked.

Is this part done via ACPI, as outlined above? Or is this done 90's style? What's the slow part of this, precisely? Is it the initialization? If so, why is it significantly faster to have the module in-kernel?

That might be worth a try.

wish I had time to. It sounds like perhaps a rather extensive project, as it touches on fundamentals of how things work. If static linking is truly a significant portion of the boot process, though, it might well be worth it. Only testing would tell.