public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: David Brownell <david-b@pacbell.net>
To: Kevin Easton <s3159795@student.anu.edu.au>, linux-kernel@vger.kernel.org
Subject: Re: Hardware Inventory [was: Re: ISA slot detection on PCI systems?]
Date: Fri, 11 Jan 2002 13:52:32 -0800	[thread overview]
Message-ID: <24b501c19aee$5e2a29c0$6800000a@brownell.org> (raw)
In-Reply-To: <20020108193604.A27539@beernut.flames.org.au>

> > > Hopefully, integration of /sbin/hotplug during the boot process (using 
> > > dietHotplug) will reduce the number of things the "coldplug" issue will 
> > > have to handle. 
> > 
> > Somewhat -- though it only handles the "load a module" 
> > subproblem. When new devices need any more setup 
> > than that, "dietHotplug" isn't enough. 
> 
> What if this was handled by the kernel not sending hotplug messages until it
> had been told that the system was ready to load drivers etc.

That would prevent dynamic loading of modules when they're needed
during the early stages of system booting, not just delay the "etc" set of
device setup subproblems.

However, there's already machinery that handles part of that "queue
up hotplug events for later delivery".  The original issue was that when
the network subsystem needed to report hotplug events, it needed to
be able to do it when some locks were held and sometimes even
in_interrupt(), so the "fork a subprocess" work had to be handed off
to some other kernel thread.


> ...or have I totally misunderstood the coldplug problem?

I suspect so.  The kernel's role with hotplug is intentionally limited:  just
tell userland policy agents "here's a device, it may need to be configured".
Configuring devices can be a complex problem, even when the driver is
already linked into the kernel.

The coldplug problem is that it's saying those things before the system
has been brought up far enough that the agents can do anything!  As in,
sometimes even before a root filesystem is mounted, and often before
other filesystems or essential system servcies are available.

So if in those cases the agent notification can't get the device set up,
then some other boot component needs to do that work.  It's better to
have one subsystem (hotplug) handling that consistently, no matter
when the device needs to be set up, than to have different code to
handle "post-boot" (hotplug) and "during-boot" (kudzu etc) cases.
Which is why the "hotplug" tools have a "coldplug" mode too.

To nudge this slightly back towards the original topic, I'll just point
out that doing this "before-boot" (as part of kernel config) is a horse
of a different color, although it needs most of the same metadata from
the kernel.  The device detection has to be done with a tool other than
the running kernel, and it never actually sets up devices for users.
All it cares about is coming up with config flags that cause the
right modules to be built and (statically or dynamically) linked.

- Dave




  reply	other threads:[~2002-01-11 22:24 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-01-04 11:32 Hardware Inventory [was: Re: ISA slot detection on PCI systems?] Martin Knoblauch
2002-01-04 22:17 ` Dave Jones
2002-01-05 17:00   ` Paul Jakma
2002-01-05 17:14     ` Dave Jones
2002-01-07 18:05       ` Patrick Mochel
2002-01-07 18:11         ` Dave Jones
2002-01-07 18:50           ` Greg KH
2002-01-07 18:58             ` Greg KH
2002-01-07 18:58               ` Eric S. Raymond
2002-01-08  8:04               ` [kbuild-devel] " Giacomo Catenazzi
2002-01-08 18:36                 ` Greg KH
2002-01-09  8:25                 ` Giacomo Catenazzi
2002-01-07 18:58             ` Dave Jones
2002-01-07 19:06               ` Greg KH
2002-01-07 19:19                 ` Dave Jones
2002-01-07 19:45                   ` Alexander Viro
2002-01-08 14:00                   ` Alan Cox
2002-01-08 14:00                     ` Erik Andersen
2002-01-07 19:19             ` Patrick Mochel
2002-01-07 19:29               ` Greg KH
2002-01-07 20:36                 ` David Brownell
2002-01-07 22:03                   ` Greg KH
2002-01-07 22:28                     ` David Brownell
2002-01-07 23:59                       ` Greg KH
2002-01-08  8:36                       ` Kevin Easton
2002-01-11 21:52                         ` David Brownell [this message]
2002-01-07 23:25       ` Kai Germaschewski
2002-01-07 17:55     ` Patrick Mochel
2002-01-07 19:04       ` Richard Gooch
2002-01-07 19:26         ` Dave Jones
2002-01-07 19:41           ` Alexander Viro
2002-01-07 19:58           ` Paul Jakma
2002-01-07 19:33         ` Patrick Mochel
2002-01-07 20:16           ` Andrew Morton
  -- strict thread matches above, loose matches on Subject: below --
2002-01-07 20:13 David Brownell

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='24b501c19aee$5e2a29c0$6800000a@brownell.org' \
    --to=david-b@pacbell.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=s3159795@student.anu.edu.au \
    /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