world leader in high performance signal processing
Trace: » hotplug

Linux Hotplugging

Often times people wish to have things run automatically after events such as insertion of a USB device. The Linux kernel provides a hotplug mechanism for this. Here we will give a brief primer to the Linux core and provide references to more extensive documentation.

Keep in mind that most hotplug utilities will allow you to create hook scripts for specific devices. This way you can still use their functionality without replacing them. Consult the configuration documentation for the utility that you're using (the uClinux-dist defaults to mdev).

Kernel Settings

Build Time

The kernel must have hotplugging enabled before you can expect things to work. In your kernel configuration, make sure you have these options turned on:

Bus options (PCI, PCMCIA, EISA, MCA, ISA)  --->
  [*] Support for hot-pluggable device

Run Time

The kernel will execute a user-specified program during run time. You can control this setting via the sysctl interface /proc/sys/kernel/hotplug. This will default to /sbin/hotplug. You can write your own script/program and update the sysctl value with the full path to your program.

uClinux-dist Settings

There are a few larger applications which can handle a variety of hotplugging tasks. Here are just a few:

  • Busybox's mdev - perfect for managing device nodes only
  • hotplug - moderately featured for managing USB and PCI
  • udev - fully featured for managing device nodes, symlinks, custom scripts, etc…

Obviously the more things the package supports, the larger and more complicated it gets. For closed embedded systems, hand written scripts/programs can easily do the job.

Hotplug Env

The kernel will pass information about the device that was loaded via the environment. Every device can pass different information and sets of environment variables, but typically these are passed along by all.

Variable Meaning
ACTION Is the device being added or removed?
DEVPATH Path in the sysfs tree to the device
FIRMWARE Name of the firmware the device would like loaded
MAJOR For devices with device nodes, the major number
MINOR For devices with device nodes, the minor number
SUBSYSTEM The subsystem the device is part of

Keep in mind that the script runs without a terminal. That means stdin/stdout/stderr are all disconnected. So if you run commands that display output (like echo), then you will not see it. You will have to redirect the output of such commands to a file and then review the text in that file.


Some devices will not work without a firmware blob being first loaded into them. The blob can be built into the kernel or loaded at runtime (depending on licensing and other such fun issues). Such device drivers will run the hotplug script and ask it to load the firmware blob into it via the sysfs file system.

You should place the firmware blobs into /lib/firmware/. This way the userspace hotplug utilities can locate it automatically.

For documentation on the actual loading process, see the files in the linux-2.6.x/Documentation/firmware_class/ folder.



If you're building an out-of-tree module that requires firmware, then you'll need this:

Device Drivers  --->
  Generic Driver Options  --->
    <*> Userspace firmware loading support


If you're using mdev from busybox, then you'll want these:

BusyBox  --->
  Linux System Utilities  --->
    [*] mdev
    [*]   Support loading of firmwares

Example Script

This is an example of “rolling your own hotplug implementation” and is meant to be educational rather than a default implementation for people to deploy. More likely you should focus on hooking in with mdev instead of programming /proc/sys/kernel/hotplug directly.

Here is a small script which will manage device nodes. Place it where ever you like in the file system and write the full path into /proc/sys/kernel/hotplug.

name=$(basename ${DEVPATH})
cd /dev
rm -f ${name}
if [ "${SUBSYSTEM}" = "block" ] ; then
if [ "${ACTION}" = "add" ] ; then
    mknod ${name} ${type} ${MAJOR} ${MINOR}

You can do just about anything here. Automatic mounting of file systems, sending e-mails, sending notices to a frame buffer, etc…

More Information

The page on dev-management is a good place to head next.

Here are some sites to consult for further information: