On Friday, October 23, 2015 11:34:34 AM Rob Herring wrote:

On Fri, Oct 23, 2015 at 10:45 AM, Tim Bird [off-list ref] wrote:

quoted

On 10/22/2015 11:53 AM, Frank Rowand wrote:

quoted

On 10/22/2015 7:44 AM, Greg Kroah-Hartman wrote:

quoted

<oops, sent too early...>

On Thu, Oct 22, 2015 at 11:05:11AM +0200, Tomeu Vizoso wrote:

quoted

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?

quoted

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

I also had the understanding that this patch series was about improving
boot time.  But I was kindly corrected that the behavior change was
getting the panel displaying stuff at an earlier point in the boot sequence,
_not_ completing the entire boot faster.

The claim for the current series, in patch 0 in v7 is:

   With this series I get the kernel to output to the panel in 0.5s,
   instead of 2.8s.

It's very common to want to get the display up before the
rest of the system.  So wanting to accelerate one part of the boot
at the expense to the rest of the system is a valid use case.
Deferred initcalls, which is out of tree primarily because it requires
the type of manual tweaking that Tomeu describes, specifically
addressed this issue.

Agreed and other folks will want other things up first. But it seems
we are getting lucky with link order with the speed ups in this case.
We need a way to specify priority of probing devices. If we have that
piece, then all this plumbing can be used. A simple solution would be
looking at stdout-path to get the console device to probe. That would
be trivial to add on top of this. That may work for the display too,
but you may not want the console on the display. That wouldn't work
for CAN bus either, but then I'm not sure there is a generic solution
for its requirements (respond within 50ms IIRC).

Well, I'm not quite sure why exactly everyone is so focused on probing here.

Probing is just one aspect of the fact that we need functional dependencies
to be tracked somehow and acted on when necessary.  And this is not limited
to probing, as I have already said for a few times.  Other cases include:
system shutdown, system suspend/resume, runtime PM, unbinding of drivers.

If there is a functional dependency between two devices (say, B requires A
to be present and functional, meaning that the driver of A has to be present
and working for the driver of B to be working), all of the above need to be
done in a specific order.

Today, however, the driver core only knows about structural dependencies
and only in the specific parent-child case.

So perhaps it's better to start discussing about a solution for the general
issue?

Thanks,
Rafael