public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Russell King <rmk@arm.linux.org.uk>
To: Kai Germaschewski <kai@tp1.ruhr-uni-bochum.de>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Initcall / device model meltdown?
Date: Fri, 17 Jan 2003 20:14:32 +0000	[thread overview]
Message-ID: <20030117201432.G13888@flint.arm.linux.org.uk> (raw)
In-Reply-To: <Pine.LNX.4.44.0301171342410.15056-100000@chaos.physics.uiowa.edu>; from kai@tp1.ruhr-uni-bochum.de on Fri, Jan 17, 2003 at 01:56:07PM -0600

On Fri, Jan 17, 2003 at 01:56:07PM -0600, Kai Germaschewski wrote:
> o Make the init order not matter. That is, make sure that the registration
>   routines ("pci_register_driver()") can be run safely even before
>   the corresponding __initcall() has executed. E.g. have 
>   pci_register_driver() only add the driver to a (statically initialized)
>   list of drivers. Then, when pci_init() gets executed, walk the list of
>   registered drivers, call ->probe() etc.

For each driver, you have up to two objects that have to be pre-initialised
and registered with the device model:

- the bus_type structure
- the device_class structure

The bus type is registered by the bus subsystem (eg, PCI), and the
device_class is registered by the driver subsystem (eg, input).

Until both of those have been initialised, you can't register the
driver (without oopsing.)  It isn't sufficient to wait for the bus
subsystem to be initialised, you need to wait for both the bus
and driver subsystems.

I suppose a solution would be for the device model could accept the
registration of a driver or device, but if the referenced objects
are not initialised, set a count of "objects requiring initialisation".

As each object is initialised, look for unregistered drivers and
decrement their initialisation count.  When it hits zero, finis the
driver registration.

-- 
Russell King (rmk@arm.linux.org.uk)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html


      reply	other threads:[~2003-01-17 20:05 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-01-17 19:23 Initcall / device model meltdown? Russell King
2003-01-17 19:32 ` Jeff Garzik
     [not found]   ` <3104.1042835842@www5.gmx.net>
2003-01-17 20:48     ` Dominik Brodowski
2003-01-17 19:56 ` Kai Germaschewski
2003-01-17 20:14   ` Russell King [this message]

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=20030117201432.G13888@flint.arm.linux.org.uk \
    --to=rmk@arm.linux.org.uk \
    --cc=kai@tp1.ruhr-uni-bochum.de \
    --cc=linux-kernel@vger.kernel.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