Quoting Dr. Nikolaus Klepp (dr.klepp@???):

> yes, 2.6 series worked that way :-)
>
> Problem is:
>
> $ uname -r
> 4.9.0-0.bpo.3-amd64

Well, exploring improved kernels is good. But I'm still puzzled about
what you're claiming the problem is. /proc/sys/kernel/hotplug is
merely something you construct (the location of the usermode helper
hotplug mechanism) -- for kernel revisions that include hotplug. But
you don't necessarily _need_ to have mdev getting uevent data via
hotplug, anyway.

As it says on https://woozle.org/neale/papers/runit-as-init.html,

Hot-plugging devices (like udev)

For a while, you could echo something into a file under /proc and the
kernel would run that for every uevent. You could set that program to
mdev from busybox, and have a pretty well working system at that point.

Newer kernels disabled support for this legacy interface. Now, you're
supposed to monitor for Netlink events. But that's not too tough, it
turns out. The kernel docs even have an example program to gather
uevents.

Picking up uevents from the kernel via a netlink
(https://en.wikipedia.org/wiki/Netlink) socket is thus the
intended long-term replacement for the older hotplug stuff. So, if your
kernel has no ability to support hotplug any more, then that's where
your dev-manager would need to get uevents from. (It's where udev now
does so, if I understand correctly.)

https://wiki.gentoo.org/wiki/Mdev#Troubleshooting and
https://landley.net/kdocs/pending/hotplug.txt
point out the sort of value one might set it to, in the case of kernels
that _do_ support hotplug, and why.

I suspect you'll find these useful, if you wish to explore further.
https://git.busybox.net/busybox/plain/docs/mdev.txt
https://github.com/slashbeast/mdev-like-a-boss
https://wiki.gentoo.org/wiki/Mdev/Automount_USB
http://data.gpo.zugaina.org/funtoo-overlay/sys-fs/mdev/files/mdev.init


Just found: a neat piece of software in the s6 suite:
https://skarnet.org/software/s6-linux-utils/s6-uevent-listener.html

s6-uevent-listener listens to the netlink interface for uevents (also
called "hotplug" or "udev" events), and writes those uevents to its
standard output, using a simple format.
[...]

s6-uevent-listener binds to the netlink interface and listens for
hotplug events, as the udev program does.
[...]

Notes

   o  s6-uevent-listener is a daemon; it should be run under a proper
      supervision system such as s6.
   o  If you are running s6-uevent-listener, prog... should be the only
      program handling uevents, which means that /proc/sys/kernel/hotplug
      should be empty.
   o  Examples of valid uses of s6-uevent-listener:
      o  s6-uevent-listener | s6-uevent-spawner mdev
      o  s6-uevent-listener | mdevd
      o  Those examples can be made safer by using a supervision 
         system: under s6 or s6-rc, write a service pipeline where 
         s6-uevent-listener is a producer and s6-uevent-spawner mdev 
         or mdevd is a consumer. This setup has the advantage, among 
         others, that you can restart the netlink listener and the 
         event handler separately. 

For my own use-case, I'm still not convinced that any of this matters,
i.e., I don't expect to have ever-changing hardware for which I need
automagical kernel handling, and any firmware loading isn't exactly
brain surgery to do with a simple init action.