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

[David Herrmann]

Hi

On Mon, Mar 9, 2015 at 8:58 PM, Ray Strode <halfline at gmail.com> wrote:
>> 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?

This should not be an issue. udev is part of base.target and should
not experience any large delays during transition. Sure, anything
involving timeouts is non-deterministic, but I would bother much
unless someone reports such issues.

Anyway, your description sounds about right. But I still think we
should drop vgacon, which makes text-mode useless in plymouth (as it
would only work on fbdev, which could be used for graphics mode by
plymouth). But if people wanna keep vgacon, I'm not going to force
them to switch..

Thanks
David