With BusyBox 1.38, you are fully covered.
Netlink daemon mode (mdev -d) was introduced back in BusyBox 1.31, meaning your version natively supports listening to the kernel's netlink interface without needing the legacy /proc/sys/kernel/hotplug file.
Simply add mdev -d to your startup script after running your initial coldplug scan (mdev -s).
For a
classic rcS startup script running under BusyBox 1.38, you can seamlessly integrate the netlink daemon by structure your script sequentially. Because standard rcS scripts run sequentially and expect services to background themselves, using mdev -d is the exact tool for the job. Here is the exact structural sequence you should add to your /etc/init.d/rcS file:
#!/bin/sh
# 1. Mount essential virtual filesystems
mount -t proc proc /proc
mount -t sysfs sysfs /sys
mount -t devtmpfs devtmpfs /dev
# 2. Trigger a coldplug scan to discover existing hardware
# This populates /dev before the daemon handles future events
mdev -s
# 3. Launch mdev in daemon mode
# The -d flag tells it to fork into the background and listen via netlink
mdev -d
Why this works perfectly here:
• No blocking: The -d flag implicitly forks mdev into the background. Your rcS script will immediately continue executing subsequent boot commands without stalling.
• Immediate response: Any USB device, MMC card, or network interface plugged in after this line executes will be caught instantly by mdev via the kernel netlink layer.
./busybox mdev --help
BusyBox v1.38.0 (2026-07-24 11:50:59 UTC) multi-call binary.
Usage: mdev [-vS] { [-s] | [-df] }
-v Verbose
-S Log to syslog too
-s Scan /sys and populate /dev
-d Daemon, listen on netlink
-f Run in foreground
Bare mdev is a kernel hotplug helper. To activate it:
echo /sbin/mdev >/proc/sys/kernel/hotplug
It uses /etc/mdev.conf with lines
[-][ENV=regex;]...DEVNAME UID:GID PERM [>|=PATH]|[!] [@|$|*PROG]
where DEVNAME is device name regex, @major,minor[-minor2], or
environment variable regex. A common use of the latter is
to load modules for hotplugged devices:
$MODALIAS=.* 0:0 660 @modprobe "$MODALIAS"
If /dev/mdev.seq file exists, mdev will wait for its value
to match $SEQNUM variable. This prevents plug/unplug races.
To activate this feature, create empty /dev/mdev.seq at boot.
If /dev/mdev.log file exists, debug log will be appended to it.mdev -d is generally faster and significantly lighter than udev, particularly regarding resource consumption and boot times on embedded or minimalist Linux systems. The introduction of the daemon mode (-d) in BusyBox version 1.31 radically improved mdev performance, closing the main efficiency gap it previously had with udev
Why mdev -d is Faster
1. No Forking Overhead per Event: Historically, mdev operated as a kernel hotplug helper, forcing the kernel to fork and execute a new mdev process for every single hardware event. Running mdev -d launches it as a persistent daemon that listens to kernel netlink events directly. This completely eliminates process creation overhead during bursts of events.
2. Reduced Feature Bloat: udev manages advanced state stores, coordinates complex hardware database queries (hwdb), handles persistent device naming schemes, and integrates deeply with systemd. mdev -d strips all of this away to focus entirely on parsing kernel uevents and creating nodes in /dev.
3. Optimised Coldplugging: During system boot, mdev -d processes initial device discovery (coldplugging) without needing a secondary scanning tool (like mdev -s), allowing the system to populate device trees in a fraction of the time.
The Trade-off
While mdev -d wins on pure speed and memory footprint, it lacks the complex feature set of udev. Modern desktop environments (like GNOME or KDE) and display servers rely heavily on udev's subsystem tracking. If you are building a containers-based architecture, an embedded system, or a lightweight distribution (like Alpine Linux or postmarketOS), mdev -d offers vastly superior performance
FYI: A.I. help was used, and technically was correct

as I search also other sources.