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/ [email protected] [email protected]
signature.asc
Description: Digital signature
-- ubuntu-devel mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
