lkml.org 
[lkml]   [2002]   [Jun]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [2.5.19] Oops during PCI scan on Alpha

    On Tue, 4 Jun 2002, David S. Miller wrote:

    > From: Patrick Mochel <mochel@osdl.org>
    > Date: Tue, 4 Jun 2002 08:50:11 -0700 (PDT)
    >
    > On Sun, 2 Jun 2002, David S. Miller wrote:
    >
    > > It's happening on every platform. It should be done before
    > > arch_initcalls actually, but after core_initcalls. I would suggest to
    > > rename unused_initcall into postcore_iniscall, then use it for this
    > > and sys_bus_init which has the same problem.
    >
    > Can't it go the other way? Instead of mass-promotion of the setup
    > functions, can't we demote the ones that are causing the problems?
    >
    > There's this middle area between core and subsys, why not
    > just be explicit about it's existence?
    >
    > Short of making the true dependencies describable, I think my
    > postcore_initcall solution is fine.

    What sense is there in naming it postcore_initcall? What does it tell you
    about the intent of the function?

    The problem is that if we have arbitrary names with arbitrary priority
    levels, people will think they're more important than most, if not all, of
    the other initcall users and leapfrog over them into earlier levels. It's
    already happened at least once, and I expect to happen more.

    The initcall levels are not a means to bypass true dependency resolution.
    They're an alternative means to solving some of the dependency problems
    without having a ton of #ifdefs and hardcoded, explicit calls to
    initialization routines.

    We can add more levels and change names. But, we should make them
    meaningful for at least two reasons:

    - It's obvious to people who are using them what they should use
    - It's obvious to someone looking at the code when it gets initialized

    That said, how about doing this:

    - core
    - subsys
    - arch
    - driver

    core initializes the core, as always.

    subsys initializes bus and device class subsystems and registers them with
    the core.

    arch does arch- and platform- specific initlization. arch_initcalls
    appear only in arch/ subdirectories, and they happen after
    subsys_initcalls.

    driver initializes all the device drivers compiled in.

    -pat

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-03-22 13:26    [W:2.129 / U:0.108 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site