Re: [patch 2/2] PNP: don't check disabled PCI BARs for conflicts in quirk_system_pci_resources()

[Rolf Eike Beer]

Ingo Molnar wrote:
> * Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote:
> > Dang.
> >
> > I guess we'll have to bite the bullet some day and actually create
> > some explicit topological ordering of initcalls rather than depend on
> > the initcall levels and link order. That is one particular complexity
> > I've tried to avoid. But the subtlety of the current ordering is
> > certainly not at all good either.
>
> 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.
>
>  [ but performance is far less important than robustness, so this idea
>    was on the backburner. ]
>
> and i think on the conceptual level initcall levels and implicit
> ordering are bad in the same way SPL and IPL based locking is worse than
> real, explicit spinlocks.
>
> 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)
>
> 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)
>
> where we create explicit dependencies between actual initcalls just by
> listing their dependencies. In many cases we could express dependencies
> in a natural way:
>
>   initcall_depends_on(some_subsys_init, kmem_cache_init);
>   initcall_depends_on(some_subsys_init, sched_init);
>
> which would express the fact that some_subsys_init() must execute after
> kmem_cache_init() and after sched_init().
>
> Each initcall is associated with an 'initcall descriptor', which shows
> which other initcalls this initcall depend on, and whether the initcall
> has been executed already.
>
> during bootup the initcall engine would parse the graph and would
> execute all the 'leaf' initcalls, and would complete the graph
> gradually.
>
> ( More details: we'd have a number of compatibility and convenience
>   symbols as well - well-known initialization stages for various
>   customary phases of bootup.
>
>   And at link time we could detect circular dependencies. )
>
> So ... this scheme looks elegant to me, but maybe it is overdesigned?

Why calculate this at boot time? Do you expect this to change between bootups?

Eike

Attachment: signature.asc
Description: This is a digitally signed message part.