Do we need hotplug?

Jürg Billeter j at
Tue Aug 16 15:10:34 PDT 2005

On Die, 2005-08-16 at 20:31 +0100, Matthew Burgess wrote:
> Jürg Billeter wrote:
> > If you're (or anybode else is) interested in this topic, I could explain
> > our approach - simplified since event recorder got upstream.
> Yep, I'd be interested, though never having had to dabble with initramfs 
> or initrd I've no idea on their potential complexity and therefore their 
> suitability for LFS.

I can't answer the question of suitability for LFS but the whole process
probably gets easier with the next kernel releases as klibc is on the
way into the kernel to carry over the rootfs mount operation from
kernelspace to userspace.

Summarized, our bootprocess works as follows:
- The kernel emits the first hotplug events at a moment where /init (the
init process of initramfs) hasn't run yet, i.e. it calls /sbin/hotplug.
In our initramfs /sbin/hotplug is a symlink to udeveventrecorder.
udeveventrecorder just creates a log file for each event received, i.e.
this does not trigger any module loading or similar actions
- The kernel executes /init with pid 1
- /init starts the udevd daemon and replays the recorded events using
udevinitsend; this triggers module loading via modalias and a minimal
udev rules file
- Now all newly occuring events get still recorded and additionally the
udevd daemon processes incoming events from the netlink socket
- As soon as the desired root device is available, it gets mounted (via
udev rule)
- /init stops the udevd daemon and then starts the udevd daemon from the
mounted root device with the option --stop-exec-queue, i.e. incoming
events will be queued only, not processed
- /proc/sys/hotplug gets unset as it isn't necessary anymore
- /init replays the recorded events using udevinitsend
- /init execs run-init (part of klibc) to start the real init and nuke
- The bootscripts call udevcontrol start_exec_queue to process the
queued events and all newly occuring events get processed immediately

If you need more details or see potential problems, just mail.


Jürg Billeter <j at>

More information about the lfs-dev mailing list