Re: hotplug TTD

[David Brownell <david-b@pacbell.net>]

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