Quoting Dr. Nikolaus Klepp ([email protected]): > 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. _______________________________________________ Dng mailing list [email protected] https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
