event based initramfs

[Steve Langasek]

On Sat, May 12, 2012 at 09:37:59PM -0400, Phillip Susi wrote:
> On 05/12/2012 08:54 PM, Steve Langasek wrote:
> > There are many ways that it could be done; using an event-based system that
> > matches the way things are done post-initramfs is probably the simplest and
> > most maintainable, however.

> Why?  It seems to me that would be much more complex than needed.  What
> opportunities are there to share init code with what is done post
> initramfs that aren't already done via udev?  The one example given in the
> meeting description is cryptsetup, but as I said before, I don't see how
> that could be done the same way at boot ( which must interact with either
> the console or plymouth ) and how it should be handled later ( with udisks
> maybe, interacting with the desktop ).

Perhaps the disconnect here is that we have differing assessments of the
quality and robustness of the cryptsetup initramfs script. :)  There is a
*lot* of polling/waiting in the cryptroot script, just as in other parts of
the initramfs, and there's also a lot of decidedly non-event-based handling
of lvm hard-coded in cryptroot because we don't have a generalized
event-driven model for root fs activation.

I think that if we had upstart in the initramfs, we would see convergence
around the cryptsetup upstart jobs.

> I guess what I'm trying to say is that the parts that should be event
> based already seem to be udev rules and share common code, and the parts
> that don't share common code can't due to requirements that are different
> at boot time than they are later.  Since udev already provides an event
> driven framework in the initramfs, why add another one?

For the exact same reason that we replaced sysvinit with upstart:  there's a
discontinuity at the boundary between udev and init scripts that can only be
satisfactorily overcome with an event-based init.  The need for this is
somewhat reduced in the case of the initramfs; but this makes it
lower-priority, not wrong.

On Thu, May 17, 2012 at 11:15:28AM -0400, Phillip Susi wrote:
> On 5/17/2012 4:37 AM, James Hunt wrote:
> >Sounds like both systems are performing initialisation to me. And as we
> >know, there is symmetry between what happens in the initramfs and what
> >then has to happen again in the main system. By using Upstart, we get
> >one tool to do that job without duplication of code.

> Sure, but upstart is performing a lot more initialization.  The only
> initialization the initramfs needs is to bring up the root device,
> which is handled mostly by udev rules, and thus, already using
> common event driven code.

I think this "mostly" is inexact.  I would say about *half* the work is
handled by the udev rules, and the other half is handled by the linear
initramfs scripts that include various sleeps, polls, wait-for-roots,
udevadm settles, and whatnots.

That second half is ugly and I would not miss it if it were to go away.

> So far the only advantage I'm seeing is that we can make a rare
> class of error messages and the luks password prompt look pretty.

Actually, no, cryptsetup *already* pulls plymouth into the initramfs.  That
part's already pretty.  It's the bits under the hood that aren't. :)

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek at ubuntu.com                                     vorlon at debian.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 828 bytes
Desc: Digital signature
URL: <https://lists.ubuntu.com/archives/ubuntu-devel/attachments/20120517/253fe1d3/attachment.pgp>