Date:	Wed, 1 Oct 2008 08:14:15 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Grant Grundler <grundler@...isc-linux.org>
cc:	Ingo Molnar <mingo@...e.hu>,
	Arjan van de Ven <arjan@...radead.org>,
	Rene Herman <rene.herman@...access.nl>,
	Bjorn Helgaas <bjorn.helgaas@...com>,
	Jesse Barnes <jbarnes@...tuousgeek.org>,
	Len Brown <lenb@...nel.org>, Frans Pop <elendil@...net.nl>,
	"Rafael J. Wysocki" <rjw@...k.pl>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	linux-pci@...r.kernel.org, linux-acpi@...r.kernel.org,
	Adam Belay <abelay@....edu>, Avuton Olrich <avuton@...il.com>,
	Karl Bellve <karl.bellve@...ssmed.edu>,
	Willem Riede <wriede@...de.org>,
	Matthew Hall <mhall@...omputing.net>,
	Sam Ravnborg <sam@...nborg.org>
Subject: Re: [patch 2/2] PNP: don't check disabled PCI BARs for conflicts in
 quirk_system_pci_resources()



On Wed, 1 Oct 2008, Grant Grundler wrote:
> > 
> > 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!
> 
> We already do this today. :)
> Definitions are in include/linux/init.h.

Absolutely. 

The problem with the current <linux/init.h> isn't that it doesn't work - 
it's worked pretty well for a long time - it's that we continually tend to 
hit the limits of the few fixed points.

I would just extend on that notion a bit, and also make the markers a bit 
more dynamic. Instead of having just 7-8 levels of initcalls, and a very 
fixed naming that is a bit misleading, I'd like to extend it to maybe 50 
levels, and the levels would be named by the subsystems and then just have 
one single place that orders them.

The old 7 levels (plus the "pure" one) would still exist, so it wouldn't 
need to be a flag-day event.

For example: why would you use "fs_initcall()" for the PnP init? The 
reason is simple: it's not a filesystem init, but it's the one that comes 
after the subsys init and before the actual low-leveld drivers. We used to 
initialize the core filesystem data (VFS) at that stage (we still do, 
although most of the actual filesystems are actually just done using the 
default module-init much later), which explains the naming, but the 
problem is that

 (a) we want to order things at a finer granularity than that
 (b) we want to have a better and more descriptive naming

but the basic notion of having a fixed ordering certainly isn't wrong (and 
I already argued against any _dynamic_ one).

> Point A would be "early" ("run before initialing SMP")
> The rest could use better definitions and AFAICT aren't that much better
> than being named "Point B".

It would be *much* better to give them symbolic names (easy enough - we 
just turn them into sections that are symbolic anyway), and then have a 
list of ordering for those symbolic names.

So they sure as hell would be much better than being named "Point B". We 
could get rid of

	subsys_initcall(pci_init)

and instead do

	initcall(pci_init, "pci");
	..
	initcall(pnp_init, "pnp");

and then just list the levels for the linker scripts in one place. So that 
we wouldn't really have to worry about link ordering: if the link ordering 
is wrong, we just add a new initcall level and insert it in the right 
place, and then we can look at the ordering and see it explicitly in one 
place instead of looking at the makefiles and checking the order we add 
object files to the list in!

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

Powered by blists - more mailing lists