Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Tue, 4 Jun 2002 15:42:13 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Tue, 4 Jun 2002 15:42:12 -0400 Received: from air-2.osdl.org ([65.201.151.6]:13703 "EHLO geena.pdx.osdl.net") by vger.kernel.org with ESMTP id ; Tue, 4 Jun 2002 15:42:11 -0400 Date: Tue, 4 Jun 2002 12:38:06 -0700 (PDT) From: Patrick Mochel X-X-Sender: To: "David S. Miller" cc: , Subject: Re: [2.5.19] Oops during PCI scan on Alpha In-Reply-To: <20020604.111337.51699424.davem@redhat.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 4 Jun 2002, David S. Miller wrote: > From: Patrick Mochel > 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/