From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Brownell Date: Thu, 11 Jan 2001 18:04:42 +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 Dave, > On Thu, Jan 11, 2001 at 08:40:44AM -0800, David Brownell wrote: > > > > Though when I started to think about how to do that stuff robustly, I > > began to wish a kernel "module" didn't stop being a visible component > > when it gets statically linked. There's a rather arbitrary line between > > static linking (build tools) and dynamic linking (modutils). Hotplugging > > a device shouldn't need to care so much how the driver module is linked. > > Yes this is useful. For PCMCIA, I created /proc/bus/pccard/drivers to > list what drivers are present, as static or modules. But a kernel > wide solution would be better (even if it is /proc/bus/*/drivers). It'd not just be "better", I suspect... The first USB hotplug "/etc/usb/policy" checked /proc/bus/usb/drivers, but the current one doesn't. Why? Because there are driver frameworks that are built on top of USB (like usb-serial, usb-storage, "input") so that multiple modules may need to get loaded. And so, lacking an explicit representation of the kernel's module structure, knowing the "usbcore" drivers that were there just wouldn't let me check if the driver actually did what I expected it to do. (Load/init OK, and bind to the device.) In the case of "input", I think the hope is that someone will donate time to create an "input" hotplug system, that USB HID (and ADB?) will be able to use; it'll cause "keybdev", "mousedev", "joydev", and so on to get loaded. But I don't think we should expect every driver framework to be that generic. A better global tool could really help robustness. It'd apply to big Linux servers, not just desktops ... the facilities needed to dynamically reconfigure a big server (downtime is bad!) aren't that different from those which prevent a desktop from needing to reboot when you install a new device. (Except that the desktop really needs to assume there's normally nobody that understands sysadmin.) > > David Hinds at one point spoke in favor of having more info passed > > to the network hotplug events than just the interface name. That's > > critical for statically configured hardware (servers); dynamically > > configured ones (pure DHCP clients, say) should not care. > > Yes, I can tell you that if only the interface name is passed, it is > going to frustrate some people who are used to having more information > from PCMCIA. It isn't entirely bad... at least, you can get the > interface's hardware address, and use that to choose configurations. > But I find it quite useful to know that eth0 is "the 3C575 card in > PCMCIA socket 1", or vice versa. This sort of issue can get sorted out as pcmcia_cs and hotplugging start to ... "co-evolve"? :-) > -- Dave _______________________________________________ Linux-hotplug-devel mailing list Linux-hotplug-devel@lists.sourceforge.net http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel