[systemd-devel] Reliably waiting for udevd to finish processing triggered events

[Ray Strode]

Hi,
>> plymouth watches for the creation of drm display devices during boot.
>> If it finds one, it starts a graphical splash and that is that.
>> However, if the system finishes loading drivers and no drm device is
>> available, it falls back onto a fbdev-based splash or a text-based
>> boot. Once it has made that choice there is no turning back, it
>> basically ignores drm devices if they become available later.
>
> To my knowledge newer versions don't do this anymore and actively
> watch drm devices coming.
We watch them coming and going but only if we haven't fallen back to text mode.
The issue is that plymouth currently only supports one kind of splash at a time
(text or graphics, not both), so if we fall back, we can't do much. it
would be weird
 if a boot started out showing a text splash then spontaneously switched to a
different graphical splash for the last split second before X came up.

There is something to be said for showing a graphical splash on a DisplayLink
device when the main machine only supports text splash, and it wouldn't be too
hard to fix, but it's a bit of a niche case, and i never got around to it.

> No, applications should not watch the queue. And the file is internal
> to udev anyway. If you watch it, you get to keep the pieces.
udev recently gained public api for monitoring the queue.
Regardless, I think using a timeout is a better way to go anyway.

key points:

1) if boot is less than say 5 seconds we shouldn't show anything but
black (which we accomplish today with the ShowSplashDelay config key)
2) if boot takes much more than 5 seconds then we need some sort of
indication that
boot is progressing, so if graphics isn't ready by then we should fall
back to text
splash (right now we only fall back after we think "coldplug
completes", so we need fixes here)
3) we shouldn't ever upgrade from text to graphics on any given
output, since that
would look weird (this works today, but we could do better by allowing
different splashes on different outputs)
4) relying on the udev queue to drain to decide on falling back is
wrong and we should stop doing that

Still, there's may be another problem...is there a decent sized hole
in boot time between udev exiting in the initrd and then starting back
up on the main root filesystem?  If so, graphics that don't manage to
get marked initialized in the initrd, may not get marked initialized
until some seconds later after they would otherwise be ready to go,
and from one boot to the next the user may get graphics or text mode.
maybe udev should stick around and switch into the root filesystem on
its own (and i guess potentially re-exec itself once it gets there),
so it doesn't have to blow it's queue and retrigger?

--Ray