[lkml]   [2000]   [Dec]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    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
    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
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 12:52    [W:0.027 / U:17.664 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site