UsplashInitramfs

Differences between revisions 2 and 3
⇤ ← Revision 2 as of 2005-11-04 20:50:18 →
Size: 1990
Editor: 62-101-126-208
Comment: USplash progess bar suggestion
← Revision 3 as of 2005-11-07 23:36:17 → ⇥
Size: 1872
Editor: 238_220_103_66-WIFI_HOTSPOTS
Comment:
Deletions are marked like this. Additions are marked like this.
Line 18: Line 18:
Bob boots his computer and sees feedback, and this makes him happy. Go Bob.
Jane boots a LiveCD and is THRILLED about all the wonderful progress bar bling.		  * Bob boots his computer and sees feedback, and this makes him happy. Go Bob.
 * Jane boots a LiveCD and is terribly excited about all the wonderful progress bar feedback while she waits for it to load.
Line 23: Line 23:
We will dedicate an arbitrary ganularity of percentage ticks to each output (both quiet and not) in initramfs, incrementing a tick counter each time, then pass that count to init/rc when we hand off control, so it knows where to begin from (so the bar doesn't jump) We will dedicate an arbitrary ganularity of percentage ticks (probably just one percent per tick) to each output step (both quiet and not) in initramfs, incrementing a tick counter each time, then pass that count to init/rc when we hand off control (by dumping our current state in /dev/initramfs/), so it knows where to begin from and the bar won't accidentally jump.
Line 25: Line 25:
 This doesn't sound like a very elegant solution IMHO, although I suppose it's the only one that would work with the current USplash.
 Let me suggest something: instead of explicitly telling USpash that it should "PROGRESS x", USplash should only be told to "PROGRESS", and magically know how much to move its progress bar.
 How? Well, at every boot, have USpash measure how long it passes between a "PROGRESS" and the next one, and have it save this information "somewhere" (the "somewhere" might be a problem, if there's no root filesystem mounted yet!).
 At the next boot, USplash will know quite precisely how to update the progress bar to make it <b>really</b> reflect the time that's left.
 This would mean no weird "jumps" in the progress bar, and accurate progress bar, and no need for less-than-beautiful solutions like passing the tick counter to init/rc.
  LjL		 This way, we get more ticks in initramfs as it is asked to perform more actions (dmsetup, very long livecd boot process, etc), rather than only dedicating a specific percentage of the boot process to initramfs.
Line 34: Line 29:
None For dapper+1, usplash will need some deeper hacking, involving making it actually aware of what a progress bar IS (currently, it just draws the bar at the length you tell it to; simple, but not very bright), so it can save its own state, and never accidentally go backwards if we mess up. For now, we're more interested in making things pretty and functional than rewriting them to make them "right".

Summary

initramfs currently doesn't output to the progress bar in usplash, only to the text output area. We would prefer it if it would do both.

Rationale

This will become more important if usplash grows a quiet/notext option, and you lose all text feedback. It's also just prettier and shinier to do this "right".

Use cases

  • Bob boots his computer and sees feedback, and this makes him happy. Go Bob.
  • Jane boots a LiveCD and is terribly excited about all the wonderful progress bar feedback while she waits for it to load.

Implementation

We will dedicate an arbitrary ganularity of percentage ticks (probably just one percent per tick) to each output step (both quiet and not) in initramfs, incrementing a tick counter each time, then pass that count to init/rc when we hand off control (by dumping our current state in /dev/initramfs/), so it knows where to begin from and the bar won't accidentally jump.

This way, we get more ticks in initramfs as it is asked to perform more actions (dmsetup, very long livecd boot process, etc), rather than only dedicating a specific percentage of the boot process to initramfs.

Outstanding issues

For dapper+1, usplash will need some deeper hacking, involving making it actually aware of what a progress bar IS (currently, it just draws the bar at the length you tell it to; simple, but not very bright), so it can save its own state, and never accidentally go backwards if we mess up. For now, we're more interested in making things pretty and functional than rewriting them to make them "right".

UsplashInitramfs (last edited 2008-08-06 16:40:56 by localhost)