Messages in this thread | | | Date | Sat, 11 Oct 2008 08:47:12 +0200 | From | Ingo Molnar <> | Subject | Re: [git pull] fastboot tree for v2.6.28 |
| |
* Arjan van de Ven <arjan@infradead.org> wrote:
> > You can try to convince me otherwise, but I really do think this > > patch is fundamentally the wrong approach. > > there's an angle here which I would like to bring up. There is a > fundamental difference between a spider functionality like USB, and > "leaf drivers". Yes USB should do it right, it's drivers are > effectively a midlayer. (and again, pull gregkh's tree and you'll get > that; although even with that there's a noticeable amount of time > spent there). > > For leaf drivers, it's a matter of where you want to push the > functionality. With leaf drivers I mean things like the ACPI battery > driver (or other ACPI drivers), but also various PCI drivers that > don't have or are elaborate subsystems or boot dependencies. We could > make all their probing functions async in each driver, or we could > provide the most simple interface as is done in this case, they just > change how they declare their initcall. (I'll grant you that we could > also do a pci_register_device_async() like of helper, but that's just > solving part of the same problem) > > Personally for leaf drivers, I think the initcall-level approach is > much less error prone.
i'd like to inject my first-hand testing experience with your patches:
When i saw your patches then initially my impression was "oh my, this will break a ton of stuff", so i asked you to: make it default-off (against Andrew's suggestion to just remove the config and make it a compulsory feature), to add various mechanisms to disable and isolate it, should it break something - which i expected to be a near certainty.
But i was wrong. We had only a single bug in fastboot-v1 three months ago which i bisected back to this series, and you fixed that quickly. And CONFIG_FASTBOOT=y is definitely one of the popular features that testers enable and there's all sorts of weird systems that are being tested with tip/master.
So tip/fastboot has certainly been a problem free topic in its 3 months of lifetime - and it got propagated to linux-next early on as well.
Our -tip testsystems boot with CONFIG_FASTBOOT=y about 50% of the time, once every couple of minutes on this test-system:
config-Fri_Oct_10_23_06_21_CEST_2008.good:CONFIG_FASTBOOT=y config-Fri_Oct_10_23_07_54_CEST_2008.good:CONFIG_FASTBOOT=y config-Fri_Oct_10_23_14_08_CEST_2008.good:CONFIG_FASTBOOT=y config-Fri_Oct_10_23_15_54_CEST_2008.good:CONFIG_FASTBOOT=y config-Fri_Oct_10_23_21_37_CEST_2008.good:CONFIG_FASTBOOT=y config-Fri_Oct_10_23_22_56_CEST_2008.good:CONFIG_FASTBOOT=y config-Fri_Oct_10_23_27_14_CEST_2008.good:CONFIG_FASTBOOT=y
i checked the logs, just yesterday that meant 354 fastboot-enabled bootups on just that single test-system. So while i fully expected fragility from this topic, neither our testing nor our testers saw fragility in practice.
Ingo
| |