March 5, 2026
Plug, pray, then post
Hardware hotplug events on Linux, the gory details
Linux USB plug saga: udev love-hate, dance pads, and AI doodles
TLDR: Linux hotplug events travel from the kernel to udev, which rebroadcasts them—one reason tools recommend udev to avoid messy timing issues. Commenters swapped war stories: udev pain, a dance pad needing a suspend-reconnect hack, and an AI-made diagram, proving hotplugging is equal parts tech and drama.
When a curious dev peeks into Linux’s gadget‑detective work, you get a wild ride: netlink (a kernel-to-app mailbox), udev (the device rule enforcer now inside systemd), and why libusb leans on udev to dodge race-condition chaos. The article maps hotplug signals, rebroadcasts, and code that listens without pulling in libudev. But the comments? That’s where the sparks fly.
User robinsonb5 dropped an XKCD-level sigh, saying the “open xorg.conf, lose happiness” joke now belongs to udev—and shared how an FPGA board shows up with unexpected USB names, sending them spelunking through rules. Then philips brought arcade energy: a bargain DDR dance pad that works when booted with it connected but fails when plugged in later—fixed with a cheeky udev “suspend then reconnect” trick. Cue a new meme: “coldplug vs hotplug is a personality test.”
Visual learners cheered when WaitWaitWha conjured a sequence diagram with “gAI dark magic,” turning jargon into storyboards. The vibe split: some praise udev as the adult in the room preventing permission snafus; others call it a mystery box that breaks simple gadgets. The thread devolved—delightfully—into war stories, memes, and DIY fixes. Honestly, the hotplug drama is hotter than the hotplug tech.
Key Points
- •libusb on Linux offers two hotplug backends: udev and netlink; the project recommends udev by default to avoid race conditions.
- •The kernel emits device uevents via netlink; udev receives these, applies rules (permissions, firmware, mode switching), and then rebroadcasts processed events.
- •udev and libudev have been integrated into systemd, so their implementations reside in the systemd codebase.
- •Netlink is a Linux-specific messaging mechanism using the BSD sockets API, suitable for kernel-to-userspace notifications with multicast support.
- •Example code outlines listening to NETLINK_KOBJECT_UEVENT, distinguishing kernel (group 1) and udev (group 2) multicast groups, and structures used for parsing.