mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Linus Torvalds <torvalds@linux-foundation.org>
To: Grant Grundler <grundler@parisc-linux.org>
Cc: Ingo Molnar <mingo@elte.hu>,
	Arjan van de Ven <arjan@infradead.org>,
	Rene Herman <rene.herman@keyaccess.nl>,
	Bjorn Helgaas <bjorn.helgaas@hp.com>,
	Jesse Barnes <jbarnes@virtuousgeek.org>,
	Len Brown <lenb@kernel.org>, Frans Pop <elendil@planet.nl>,
	"Rafael J. Wysocki" <rjw@sisk.pl>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	linux-pci@vger.kernel.org, linux-acpi@vger.kernel.org,
	Adam Belay <abelay@mit.edu>, Avuton Olrich <avuton@gmail.com>,
	Karl Bellve <karl.bellve@umassmed.edu>,
	Willem Riede <wriede@riede.org>,
	Matthew Hall <mhall@mhcomputing.net>,
	Sam Ravnborg <sam@ravnborg.org>
Subject: Re: [patch 2/2] PNP: don't check disabled PCI BARs for conflicts in quirk_system_pci_resources()
Date: Wed, 1 Oct 2008 08:14:15 -0700 (PDT)	[thread overview]
Message-ID: <alpine.LFD.2.00.0810010800510.11040@nehalem.linux-foundation.org> (raw)
In-Reply-To: <20081001061328.GD7348@colo.lackof.org>



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

  parent reply	other threads:[~2008-10-01 15:16 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-09-29 15:53 [patch 0/2] don't check disabled PCI BARs for conflicts with PNP devices Bjorn Helgaas
2008-09-29 15:56 ` [patch 1/2] PCI: add pci_resource_enabled() Bjorn Helgaas
2008-09-29 15:57 ` [patch 2/2] PNP: don't check disabled PCI BARs for conflicts in quirk_system_pci_resources() Bjorn Helgaas
2008-09-29 16:34   ` Linus Torvalds
2008-09-29 18:31     ` Rene Herman
2008-09-29 19:13       ` Linus Torvalds
2008-09-30  9:19         ` Rene Herman
2008-09-30 14:48           ` Linus Torvalds
2008-09-30 15:57             ` Rene Herman
2008-09-30 16:29               ` Linus Torvalds
2008-09-30 17:10                 ` Linus Torvalds
2008-09-30 17:21                   ` Linus Torvalds
2008-09-30 19:29                     ` Rene Herman
2008-09-30 19:37                       ` Rene Herman
2008-09-30 19:44                       ` Linus Torvalds
2008-09-30 20:48                         ` Rene Herman
2008-09-30 19:38                     ` Ingo Molnar
2008-09-30 19:51                       ` Linus Torvalds
2008-09-30 19:54                         ` Arjan van de Ven
2008-09-30 20:01                         ` Ingo Molnar
2008-10-01  6:13                         ` Grant Grundler
2008-10-01  8:26                           ` Ingo Molnar
2008-10-06  5:34                             ` Grant Grundler
2008-10-01 15:14                           ` Linus Torvalds [this message]
2008-10-01 16:21                             ` Yinghai Lu
2008-09-30 20:05                       ` Rolf Eike Beer
2008-10-01  8:52                         ` Ingo Molnar
2008-09-30 18:01                 ` Linus Torvalds
2008-09-30 18:13                   ` Linus Torvalds
2008-09-30 19:51                     ` Rene Herman
2008-09-30 19:16                   ` Bjorn Helgaas
2008-09-30 19:12                 ` Bjorn Helgaas
2008-10-01 20:18                   ` Bjorn Helgaas

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alpine.LFD.2.00.0810010800510.11040@nehalem.linux-foundation.org \
    --to=torvalds@linux-foundation.org \
    --cc=abelay@mit.edu \
    --cc=arjan@infradead.org \
    --cc=avuton@gmail.com \
    --cc=bjorn.helgaas@hp.com \
    --cc=elendil@planet.nl \
    --cc=grundler@parisc-linux.org \
    --cc=jbarnes@virtuousgeek.org \
    --cc=karl.bellve@umassmed.edu \
    --cc=lenb@kernel.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=mhall@mhcomputing.net \
    --cc=mingo@elte.hu \
    --cc=rene.herman@keyaccess.nl \
    --cc=rjw@sisk.pl \
    --cc=sam@ravnborg.org \
    --cc=wriede@riede.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®