Opened 17 years ago

Closed 15 years ago

#1068 closed enhancement (invalid)

Migration to managed hotplug events incomplete

Reported by: alexander@… Owned by: lfs-book@…
Priority: lowest Milestone:
Component: Book Version: SVN
Severity: minor Keywords:


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.

Change History (12)

comment:1 by andy@…, 17 years ago

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

comment:2 by Matthew Burgess, 17 years ago

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?

comment:3 by randy@…, 17 years ago

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.

comment:4 by Matthew Burgess, 17 years ago

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.

comment:5 by alexander@…, 17 years ago

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.

comment:6 by alexander@…, 17 years ago

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?

comment:7 by jim@…, 17 years ago

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.

comment:8 by alexander@…, 17 years ago

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?

comment:9 by jim@…, 17 years ago

Priority: lowlowest
Resolution: later
Status: newclosed

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.

comment:10 by jim@…, 17 years ago

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

comment:11 by alexander@…, 15 years ago

Resolution: later
Status: closedreopened

Reopening since Trac doesn't allow direct changes of resolution

comment:12 by alexander@…, 15 years ago

Resolution: invalid
Status: reopenedclosed

This bug is obsolete since hotplug removal.

Note: See TracTickets for help on using tickets.