From: "Grover, Andrew" <andrew.grover@intel.com>
To: linux-hotplug@vger.kernel.org
Subject: RE: hotplug TTD
Date: Wed, 10 Jan 2001 06:34:48 +0000 [thread overview]
Message-ID: <marc-linux-hotplug-97910854014871@msgid-missing> (raw)
In-Reply-To: <marc-linux-hotplug-97901650309422@msgid-missing>
Is it unreasonable, long-term, to move towards a unified Linux hotplug
architecture?
Under both Windows and BeOS, a given bus driver is responsible for
enumerating the devices on it, and it tells a central "configuration
manager", who then is the one who loads the drivers.
Having one entity who knows about all devices on a system is also great for
power management, and implementing suspend-to-memory and suspend-to-disk.
Thoughts?
Regards -- Andy
> From: Adam J. Richter [mailto:adam@yggdrasil.com]
> Perhaps I'm just being pedantic, but I'd like to just clarify
> that many of the Linux-related facilities that people refer to as
> "hot plugging" in are not really hot plugging, but rather a set of
> facilities used by most of the kernel hot plugging schemes:
>
> 1. a standardized hardware identification scheme
> for the bus in question (ISAPnP, PCI, USB, other
> systems covered by Intel Plug'n'Play
> standards, etc.)
>
> 2. a facility for dynamically loading kernel driver
> modules for that bus.
>
> 3. A MODULE_DEVICE_ID table for that format in each
> relevant driver.
>
> 4. Support for that ID table format in depmod
>
> 5. A user level program that reads the
> appropriate depmod
> modules.___map and figures out which
> modules to load.
>
> For example, I understand that ISAPnP hardware is not
> capable of hot plugging, but it uses these same facilities.
> Conceivably, other non-hotplug busses that have quasi-standard
> schemes for hardware enumeration could use these facilities
> as well (NuBus? S-Bus?).
_______________________________________________
Linux-hotplug-devel mailing list
Linux-hotplug-devel@lists.sourceforge.net
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
next prev parent reply other threads:[~2001-01-10 6:34 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-01-09 4:59 hotplug TTD Morton, Andrew [WOLL:4009-M:EXCH]
2001-01-09 5:47 ` Miles Lane
2001-01-09 6:55 ` Miles Lane
2001-01-09 8:49 ` Adam J. Richter
2001-01-09 17:09 ` David Brownell
2001-01-09 17:38 ` David Brownell
2001-01-10 6:20 ` Grover, Andrew
2001-01-10 6:34 ` Grover, Andrew [this message]
2001-01-10 10:58 ` Andrew Morton
2001-01-10 10:58 ` Andrew Morton
2001-01-10 10:59 ` Andrew Morton
2001-01-11 16:10 ` David Brownell
2001-01-11 16:40 ` David Brownell
2001-01-11 17:18 ` David Hinds
2001-01-11 18:04 ` David Brownell
2001-01-12 0:09 ` Grover, Andrew
2001-01-12 0:33 ` Grover, Andrew
2001-01-12 1:13 ` Grover, Andrew
2001-01-12 12:51 ` Andrew Morton
2001-01-12 16:42 ` David Brownell
2001-01-12 17:37 ` David Brownell
2001-01-12 23:45 ` Keith Owens
2001-01-13 18:54 ` David Brownell
2001-01-13 23:25 ` Keith Owens
2001-02-03 23:37 ` Miles Lane
2001-02-03 23:48 ` Keith Owens
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=marc-linux-hotplug-97910854014871@msgid-missing \
--to=andrew.grover@intel.com \
--cc=linux-hotplug@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.