Thread (101 messages) 101 messages, 22 authors, 2015-10-27

Re: [GIT PULL] On-demand device probing

From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date: 2015-10-22 14:44:13
Also in: dri-devel, linux-clk, linux-devicetree, linux-gpio, linux-i2c, linux-pm, linux-pwm, linux-tegra, lkml

<oops, sent too early...>

On Thu, Oct 22, 2015 at 11:05:11AM +0200, Tomeu Vizoso wrote:
But that's moot currently because Greg believes that the time spent
probing devices at boot time could be reduced enough so that the order
in which devices are probed becomes irrelevant. IME that would have to
be under 200ms so that the user doesn't notice and that's unicorn-far
from any bootlog I have ever seen.
But as no one has actually produced a bootlog, how do you know that?
Where exactly is your time being spent?  What driver is causing long
delays?  Why is the long-delay-drivers not being done in their own
thread?  And most importantly, why are you ignoring the work that people
did back in 2008 to solve the issue on other hardware platforms?
Given that downstreams are already carrying as many hacks as they
could think of to speed total boot up, I think this is effectively
telling them to go away.
No I'm not, I'm asking for real data, not hand-wavy-this-is-going-to
solve-the-random-issue-i'm-having type patch by putting random calls in
semi-random subsystems all over the kernel.

And when I ask for real data, you respond with the fact that you aren't
trying to speed up boot time here at all, so what am I supposed to think
other than that you don't care enough to do the real work and are trying
to hack the driver core up instead.
Sorry for the rant,
No apologies needed, it's cathartic at times :)

thanks,

greg k-h
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help