lkml.org 
[lkml]   [2008]   [Sep]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [patch 2/2] PNP: don't check disabled PCI BARs for conflicts in quirk_system_pci_resources()
Date
Ingo Molnar wrote:
> * Linus Torvalds <torvalds@linux-foundation.org> 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
[unhandled content-type:application/pgp-signature]
\
 
 \ /
  Last update: 2008-09-30 22:09    [W:0.065 / U:0.220 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site