event based initramfs

[Phillip Susi]

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.

> Upstart provides a "udev bridge" that allows arbitrary jobs to react to
> udev events without having to install udev rules in one of the 3 udev
> locations (although I guess that's really potentially 5 if you include
> the initramfs locations (but exclude /run)). For the cases where you
> aren't modifying devices, it makes working with udev much simpler.

Yes, I know upstart can build more layers on top of the udev events, but 
what I don't understand is why you would want to.  What I am looking for 
is a specific example of something you want upstart to do above the udev 
rules that both needs done while the system is fully up and running, and 
also needs done to find the root fs.

> The code for mountall is admittedly more complex than simply calling
> 'mount', but it has the following advantages:
>
> - it actually performs error checking (unlike the initramfs mount code).

And what would you do in the event of an error?  If the fs is so damaged 
that it can't be mounted, then about all you can do is report the error 
to the user and halt or drop them to the busybox shell.  So I guess what 
you are saying is that you want a pretty plymouth error message instead 
of plain console text?

> - it provides user feedback on the operations via Plymouth.
> - it runs fsck and provides feedback to the user via Plymouth.

So you also want to put all of the fscks and their dependencies in the 
initramfs?  Or it would only do this for non root filesystems?  Why 
would we want to do this in the initramfs instead of when the real init 
runs?

AFAIK, plymouth is not currently in the initramfs because it was decided 
that adding it and the rather sizable graphics drivers that it depends 
on would bloat the initramfs too much, so why do we now want to not only 
add all of that, but upstart and mountall as well?

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.  I can see the 
argument for that, but does it really require upstart and mountall too?

> That's not actually what we're talking about here - the upstreams are
> moving tooling currently in / to /usr. We might be able to work around
> this, but it sounds like it will become increasingly difficult to do so.

What upstream doesn't support the normal configure switches to set the 
install directory, and that mountall depends on?