From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Grover, Andrew" Date: Wed, 10 Jan 2001 06:34:48 +0000 Subject: RE: hotplug TTD Message-Id: List-Id: References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: linux-hotplug@vger.kernel.org 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