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.