| |||||||||||||
LinuxCon: A tale of two bootchartsLinuxCon: A tale of two bootchartsPosted Aug 27, 2010 18:00 UTC (Fri) by Trelane (subscriber, #56877)In reply to: LinuxCon: A tale of two bootcharts by BenHutchings Parent article: LinuxCon: A tale of two bootcharts
I am painfully aware that I'm hitting the envelope of my knowledge, pretty hard.
"The annoying thing about driver modules is that module initialisation, which includes binding to and probing all the devices they can handle, is serialised."
It strikes me, however, that the basic problem *here* is finding out what hardware is present and not present. In the vast majority of cases, I'd wager that this really only needs done once (rather like the crypto hardware tests): upon installation. Beyond that, what's needed is graceful fallback for the rarer cases the hardware isn't present anymore, and what we already have: new hardware detection.
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.) If intialization of the known hardware fails, then it could perhaps fall back to probing.
(Log in to post comments)
LinuxCon: A tale of two bootcharts Posted Aug 27, 2010 20:13 UTC (Fri) by BenHutchings (subscriber, #37955) [Link] 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.
|
|||||||||||||