From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Brownell Date: Tue, 09 Jan 2001 17:38:34 +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 Hi Adam, > 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: I don't think there's been a strict definition of "hotplugging", but you're _absolutely right_ that what we've got is a collection of facilities that need to be reasonably well integrated. Which is one of the challenges in growing it, moving forward. > 1. a standardized hardware identification scheme > for the bus in question (ISAPnP, PCI, USB, other > systems covered by Intel Plug'n'Play standards, etc.) That's pretty much what the original "PCI Hotplug" config option did. It's evolved a bit since then ... ;-) > 2. a facility for dynamically loading kernel driver > modules for that bus. That's one of the subtasks "/sbin/hotplug" (CONFIG_HOTPLUG) enables; but not the only one. > 3. A MODULE_DEVICE_ID table for that format in each > relevant driver. > > 4. Support for that ID table format in depmod Also within each bus framework ... USB, PCI, and ISAPNP use those tables when binding drivers to devices. > 5. A user level program that reads the appropriate depmod > modules.___map and figures out which modules to load. And there's more: - "Network hotplugging" isn't specific to any given bus, it works for all network devices. - I suspect that "SCSI" hotplugging (like "input" hotplugging) will be more what one might think of as a "logical" bus that needn't correspond to any particular type of hardware. (USB storage device, even flash memory, are virtual SCSI devices; the input subsystem isn't USB-specific.) - It includes device configuration, not just module loading; Hotplugging is useful even on fully static kernels. Basically, "plug the device in and it's immediately usable" is the goal of hotplugging. So it's got to cover more than just device-to-driver binding issues; in some cases it'll need to know how to notify applications about new devices they should be managing. > 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?). Yes. I usually think of hotplug as "autoconfiguring Linux". The same kinds of facilities (and "design patterns" if I can mention that here without getting shot!) can apply in many contexts. For example, I think there's no virtue to having separate ways to configure USB or PCI devices depending on whether they were there at powerup time ("cold plugging") or were plugged in later ("hot" pluggging). Once I start thinking that way, I think "hotplug" maybe wasn't the perfect name ... not that I know a better one, of course! - Dave _______________________________________________ Linux-hotplug-devel mailing list Linux-hotplug-devel@lists.sourceforge.net http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel