pup_eventd split into backend and frontend

I've been doing some major coding. In 4.1alpha2, /sbin/pup_eventd is started when X starts. There was a little helper daemon named pup_bootd for loading firmware earlier in the bootup. The scripts /etc/rc.d/rc.modules and rc.modules2 are responsible for loading modules at bootup, and pup_eventd takes over for hotplug support.

There are some issues with that configuration, and I undertook to resolve them. I have split pup_eventd into pup_event_backend_d and pup_event_frontend_d. The former starts early as possible at bootup, the latter when X starts. The backend script keeps running right through -- it receives uevents from the kernel and loads modules and firmware. It also passes messages to the frontend script related to updating the desktop icons and some other stuff.

I came to a stop this morning though, as there was something I did not understand. I am starting pup_event_backend_d at the beginning of /etc/rc.d/rc.sysinit, however it does not receive many uevents. This is because they have mostly occurred earlier in the bootup. The backend script does receive later hotplug events ok though.

If the backend script can get all uevents, then I think that I can retire most of the code in rc.modules and rc.modules2 that parses /sys looking for 'modalias' files. Those scripts find all the modalias files then convert them to module names then load the modules. It works well, and it finds more modules than earlier puppies.

The thing is though, very early in bootup, I think that the kernel will post all these modaliases as uevents, and it is really good to hook into this as modules can then be loaded in order that the kernel is finding the hardware. At least that's how I think it works.

It seems that I might have to run 'udevtrigger', a utility from the 'udev' package. As usual though, adequate documentation is lacking. I have hunted around, and find snippets of conversation about it, like this:

[11:05] <Md> udevtrigger must be run exactly once (at boot time) and never again
[11:08] <mbiebl> Then either the udevtrigger has to create some kind of lock file on startup (in /var/run) and when invoked a second time it simply does nothing when this file exists
[11:08] <mbiebl> Or we would need something like a "once" keyword in upstart.
[11:09] <Md> I think it should be possible to create some condition to run an event only once
[11:09] <Md> udevtrigger cannot do anything by itself because it's usually run at a time where / is mounted ro, so if there is some rw fs available it's a distro-specific issue

And it seems that I will have to use 'udevsettle' as it takes awhile, as this code snippet shows:

# Log things that udevtrigger does (won't work on seb's machine)
10 if [ -x /usr/sbin/udevmonitor ]
11 then
12 /usr/sbin/udevmonitor -e >/dev/.udev.log &
13 UDEV_MONITOR_PID=$!
14 fi
15
16 # Fix permissions and missing symlinks/programs for devices made in
17 # initramfs, and catch up on everything we missed
18 echo "Loading hardware drivers..."
19 /sbin/udevtrigger
20 /sbin/udevsettle --timeout=60
21
22 # Kill the udevmonitor again
23 if [ -n "$UDEV_MONITOR_PID" ]
24 then
25 kill $UDEV_MONITOR_PID
26 fi

There are some reports that making the kernel regurgitate all the uevents is slow. I'll try it, and if it is too slow then I'll keep my code that parses /sys and finds all the 'modalias' files.

This is another useful script from the LFS people:

Tags: puppy