lkml.org 
[lkml]   [2000]   [Dec]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: hotplug mopup
> - I don't think we can say that the kernel hotplug interface is
> complete until we have real, working, tested userspace tools. David,
> could you please summarise the state of play here? In particular,
> what still needs to be done?

I think there's a lot of scope for more and better userspace tools, and we
have a great starting point with the latest 2.4 kernels. I think such tools
are pretty well _enabled_ now by the kernel. Some drivers don't yet help to
autoconfigure their devices; that'll come with time.


There's the "reference" /sbin/hotplug (CVS at linux-usb.sourceforge.net)
that makes a lot of devices usable immediately after you plug them in to
USB or CardBus. Real and working ... but more testing is always good.
(I got a bug report yesterday ... :-)

- Prefers to delegate to /etc/hotplug/$TYPE.agent if that's there,
otherwise it falls back to simple algorithms (next bullets).

- When new USB or PCI/Cardbus devices get added, driver modules
will get loaded (and maybe initialized). For 2.4 based systems,
drivers need a MODULE_DEVICE_TABLE for the driver to load.

- There's a convention that /etc/hotplug/$TYPE/$MODULE startup scripts
will get run. This hook lets you do things like running a program
to talk to your PDA (call from /etc/hotplug/usb/visor) or printer.

- When a new network device is registered, and "/sbin/ifup" is there,
it's invoked to try bringing up the device.

For 2.2.18 systems, USB hotplugging works (or so I'm told :-) using an older
approach to the problem solved by MODULE_DEVICE_TABLE in 2.4.x kernels.


One thing that needs to be done: figure out how to evolve the user mode
software moving forward. Right now that's one script, but I forsee smarter
hotplug agents complicating the picture. Life will be simpler if all distros
can share both core functionality (/sbin/hotplug) and ways to extend it (like
/etc/hotplug conventions). It'd happen more easily if we put "/sbin/hotplug"
into some official tool package (say, modutils) but that's not the only way.


As for system "hotplug" class functionality that's missing, "pcmcia_cs" is
a partial blueprint. Some of this needs kernel support:

- There's no Cardbus support for stuff like "cardctl eject", which
would call the PCI driver remove() method and let the driver shut
down cleanly while the device is still connected. I suspect a
solution like new ioctls on /proc/bus/pci files could solve that.

- Similarly with USB; though there's no tool like "cardctl" that
folk are no expecting to use. (If PCMCIA really needs tools to
cleanly shut down drivers, then it'd seem other hotplug busses
must too ... but nobody's suffering for this USB feature now.)

- Unless I missed a recent patch, only Cardbus (PCI) drivers get
hotplug notifications, not PCMCIA (ISA-ish) ones ... so there's
currently still a need for "cardmgr" if you're using PCMCIA cards.
(Getting rid of it isn't a 2.4.0 task; maybe not a 2.4.x task.)

- There's a feeling that IEEE 1394, SCSI, disk partitions, input,
and other sorts of Linux driver frameworks should move towards
autoconfiguration ("hotplug") ... surely not 2.4.0 issues!

There's some other stuff that seems less likely to need kernel changes:

- 'remove' events are ignored ... something else must unload modules,
like the "rmmod -as" cron job some systems run, or smarter agents
to handle the "remove" hotplug events.

- Devices that are recognized at boot before the root filesystem is
mounted are not going to get configured by /sbin/hotplug ...
something needs to run after root is mounted, scanning the busses
(/proc/bus/pci; and usbdevfs in /proc/bus/usb if it's configured
and mounted) and effectively faking hotplug events.

- For 2.4.x systems with "pcmcia_cs", the network hotplugging has
kicked in before the "pcmcia_cs" support doing the same stuff.
Something smart should IMHO remove that overlap, preferably by
making this something pcmcia_cs just doesn't do any more.

- More documentation will likely be needed.

All those additional usermode-only behaviors would seem to strongly benefit
from Linux standards for the relevant sysadmin and booting procedures, but
as I understand it they don't exist yet.

- Dave




-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 12:52    [W:0.049 / U:0.260 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site