Migration to managed hotplug events incomplete

[alexander@…]

Although the "udev" initscript now sets /proc/sys/kernel/hotplug to /sbin/udevsend, there are a few more steps to do. 1) To avoid future incarnations of Bug 842 and prevent junk device nodes from appearing in the real /dev (right now we just ignore them), add the following commands to hotplug installation instructions: rm /sbin/hotplug # because /sbin/udevsend does everything /sbin/hotplug did sed -i s@/sbin/hotplug@/etc/hotplug/pci.agent@ /etc/hotplug/pci.rc In "Short descriptions", remove the description of /sbin/hotplug, or, better, replace it with the reference to udevsend. 2) On the udev page, optionally add the following command: rm /etc/hotplug.d/default/10-udev.hotplug That symlink is needed only in non-managed mode. In managed mode, if this symlink is present, the following happens: a) The kernel calls /sbin/udevsend in order to inform userspace about the hotplug event b) udevsend transfers that information to udevd c) udevd calls handlers in /etc/dev.d and /etc/hotplug.d, including that symlink d) /sbin/udevsend is called again through that symlink. It detects a loop and exits immediately. Removal of that symlink optimizes things a bit by removing that loop.

[andy@…]

I'm a bit worried by the suggestion to remove /sbin/hotplug. Can udevsend load firmware into usb devices. I don't have any modules, the kernel is a monolith, but I need hotplug to load the firmware into my speedtouch modem. If I rm -f /sbin/hotplug I won't be able to connect to the internet

[Matthew Burgess]

I must admit to being a little surprised at the explicit removal of the hotplug binary too. What harm does it do if it remains on the system? Are we sure there aren't any other packages/scripts that depend on it being present in the presence of the other scripts in /etc/hotplug.d?

[randy@…]

Did you look at the script, Matt? It is rather simple and doesn't appear to do very much. Referencing it as a binary is a bit of a stretch.

[Matthew Burgess]

Wow, now I really do look like a fool! I even read up on what the script does a few days ago. Still, my point stands that there may be other stuff out there that expects the script to be present when its accompanying .rc and .agent scripts are present.

[alexander@…]

udev.c contains the following in the line 233:

udev_multiplex_directory(&udev, HOTPLUGD_DIR, HOTPLUG_SUFFIX);

this is an equivalent of the old /sbin/hotplug script. So, firmware loading will work. As for the programs that want to provide synthetic hotplug events by call /sbin/hotplug directly: tough question, beyond BLFS. Any concrete example? Such programs are going to have issues anyway because udev adds environment variables not present in the original hotplug event (and handlers may rely upon it), and those programs don't.

[alexander@…]

On the second thought, I wonder how Andrew Benton can load firmware right now, with /sbin/hotplug and non-modular kernel. Won't the hotplug event just get lost because it may happen before mounting the root filesystem?

[jim@…]

Alex, This is invalid since, I have worked with Kay Sievers on how we are doing hotplug/udev. Currently he says, we have everything the way it should be. Hotplug is still a necessary and vital part or the process flow. Yes udevsend takes care of some issues, but hotplug is still needed for other reasons. Once hotplug-ng is fully functional, it will change this whole process. I'm recommending closing this as invalid, and thank you for you insight. Everything works currently.

For the record, our current LFS hotplug/udev configuration works the way it was intended to by the authors. The future of this will be changing.

[alexander@…]

jim: Please forward mail from Kay Sievers where he explicitly says that we should ignore the fact that udev creates devices in real /dev (e.g. due to modules probed via the "modules" script) before we mount tmpfs on /dev. Also, have you checked that he was saying "OK" to the development branch, not LFS 6.0?

[jim@…]

After speaking with Alex, I'm going to put this ticket on hold. The issues he has discussed here, will be fixed with the new version of hotplug, hotplug-ng. Right now it doesn't have support for cold plugging, when it does the modules script will be removed.

[jim@…]

More Notes: A move of the modules script to BLFS, to support ppp and other non pluggable modules may be needed.

[alexander@…]

Reopening since Trac doesn't allow direct changes of resolution

[alexander@…]

This bug is obsolete since hotplug removal.