Re: hotplug TTD

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

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