lkml.org 
[lkml]   [2008]   [Sep]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [patch 2/2] PNP: don't check disabled PCI BARs for conflicts in quirk_system_pci_resources()


On Tue, 30 Sep 2008, Ingo Molnar wrote:
>
> incidentally, i've been talking to Arjan about this recently in context
> of the CONFIG_FASTBOOT feature. Because, as a side-effect, in the long
> run, once the dependencies between initcalls fan out in a more natural
> way, with explicit initcall ordering we'll also be able to boot a bit
> faster and a bit more parallel.

Hell no.

We do not want any implicit parallelism in the initcalls. That way lies
madness.

The probe functions that explicitly know that they are slow (like USB
detection and/or other individual drivers that have timeouts) should put
themselves in the background. We should _not_ use the dependency chain to
do so automatically, because for most cases drivers are totally
independent, but we still want a _reliable_ and _repeatable_ ordering.

Which means that I will not accept stuff that makes for a parallel bootup
as a general initcall notion. I want things like network devices to show
up in the same order for the same kernel, thank you very much - even if
there is absolutely _zero_ ordering constraints between two independent
network drivers.

Anything else will inevitably cause just totally random and undebuggable
problems.

> i think the topological ordering should not be just an extension of the
> current hardcoded initcall levels, but it should be symbol space based:
> i.e. an initcall should depend not on some kind of artificial enum, but
> it should depend on _another initcall_. (a list of initcalls more
> generally)

Yes, it should be explicit.

However, I don't agree with the notion of having initcalls point to other
initcalls. One big _idea_ of initcalls is that you can put them anywhere
in the source code, and that CONFIG_XYZ variables will automatically run
them or not depending on whether the code was compiled in. Having
something like:

> so instead of the current hardcoded levels:
>
> core_initcall(sysctl_init);
>
> we could have natural constructs like:
>
> initcall_depends_on(sysctl_init, securityfs_init);
> initcall_depends_on(sock_init, sysctl_init)

would be a TOTAL DISASTER, because if you do that, then you are
essentially back to the insane situation where people need to know what
other parts are enabled.

So no. No "one call depends on another" crap.

But I think we could add a separate notion of a dependancy point, and have
a setup where we describe "initcall X needs to happen before point A" and
"initcall Z needs to happen after point A".

And then we can create a separate set of these dependency points, so that
X and Y don't have to know about each other, they just have to have some
knowledge about some common synchronization point - one that exists
regardless of whether X or Y are even compiled in!

Linus


\
 
 \ /
  Last update: 2008-09-30 21:57    [W:0.062 / U:0.192 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site