On Mon, Oct 19, 2015 at 06:21:40PM +0200, Geert Uytterhoeven wrote: > Hi Russell, > > On Mon, Oct 19, 2015 at 5:35 PM, Russell King - ARM Linux > <linux@xxxxxxxxxxxxxxxx> wrote: > >> > What you can do is print those devices which have failed to probe at > >> > late_initcall() time - possibly augmenting that with reports from > >> > subsystems showing what resources are not available, but that's only > >> > a guide, because of the "it might or might not be in a kernel module" > >> > problem. > >> > >> Well, adding those reports would give you a changelog similar to the > >> one in this series... > > > > I'm not sure about that, because what I was thinking of is adding > > a flag which would be set at late_initcall() time prior to running > > a final round of deferred device probing. > > Which round is the final round? I said "a" not "the". Maybe I should've said "one last round of deferred probing before entering userspace". > That's the one which didn't manage to bind any new devices to drivers, > which is something you only know _after_ the round has been run. > > So I think we need one extra round to handle this. Yes - because the idea is that we do everything we do today without printing anything about deferred probes. We then set a flag which indicates we should report defers, and then we trigger another round of probes. If everything probed successfully, the deferred probe list will be empty and nothing will be seen. Otherwise, we should end up with a report of all the devices that weren't able to be bound to their drivers due to -EPROBE_DEFER. > > > This flag would then be used in a deferred_warn() printk function > > which would normally be silent, but when this flag is set, it would > > print the reason for the deferral - and this would replace (or be > > added) to the subsystems and drivers which return -EPROBE_DEFER. > > > > That has the effect of hiding all the deferrals up until just before > > launching into userspace, which should then acomplish two things - > > firstly, getting rid of the rather useless deferred messages up to > > that point, and secondly printing the reason why the remaining > > deferrals are happening. > > > > That should be a small number of new lines plus a one-line change > > in subsystems and drivers. > > Apart from the extra round we probably can't get rid of, that sounds > OK to me. Yes, it means a little longer to boot, but if there's nothing pending this _should_ only be microseconds - it should be nothing more than setting the flag, possibly taking and releasing a lock, and checking that the deferred probe list is empty. Of course, if the deferred probe list isn't empty, then there'll be more expense - but I'm willing to bet that for those developers with serial console enabled, the kernel boot will be faster overall due to the reduced number of characters printed during the boot. -- FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up according to speedtest.net. -- To unsubscribe from this list: send the line "unsubscribe dmaengine" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
