Ideas for completing WIP "add unit to switch back to initrd at shutdown" etc

[Alan Jenkins]

On 12/06/2018, Ray Strode <halfline at gmail.com> wrote:
> Hi,
>
> On Tue, Jun 12, 2018 at 12:22 PM Alan Jenkins
> <alan.christopher.jenkins at gmail.com> wrote:
>> I might be abusing your terminology.  And I'm slightly vague about
>> "drm-escrow", but I think I've been assuming I can have plymouthd exec()
>> into "drm-escrow".  Then there is no child process :-) and there's a
>> natural way to detect if exec() of drm-escrow fails e.g. because the
>> initrd was rebuilt without plymouth.  I guess I should check my
>> assumption by working on this part first.
> I hadn't considered that.  If you go that approach, you may need to
> audit all the places fd's are created to ensure they're CLOEXEC.
>
>> I think the fdstore wouldn't help with the design.  (I'm familiar with
>> it from how logind uses the fdstore for drm devices).
> Why not?  Admittedly, I haven't looked into it in detail, beyond the
> man page, so you may understand the API better than me.  But
> fundamentally, the drm fd just needs to be open, it shouldn't matter
> who is holding the fd (be it plymouthd / plymouth-drm-escrow / or
> systemd)
>
> --Ray

I think the FD will be closed when you exit plymouthd to stop it
pinning the rootfs.  Because when a service stops, systemd cleans up
the fdstore for that service.  It's only intended for immediate
restarts.

Question for you: is there a reason for keeping the DRM fd? In simple
cases you don't need it, you can let the VT stay in KD_GRAPHICS mode
and that's it. Just like the smooth plymouth -> gdm transition (which
effectively uses `plymouth quit --retain-splash`).

I don't see a big problem keeping the drm fd, since I'd like to have a
drm-escrow around that can switch back to KD_TEXT anyway.  I'm just
not 100% sure what it would be doing.

Alan