UsplashInitramfs

Differences between revisions 4 and 5
Revision 4 as of 2005-11-07 23:51:28
Size: 2400
Editor: 238_220_103_66-WIFI_HOTSPOTS
Comment:
Revision 5 as of 2005-11-08 20:39:25
Size: 2399
Editor: 156_220_103_66-WIFI_HOTSPOTS
Comment: fix typo
Deletions are marked like this. Additions are marked like this.
Line 27: Line 27:
A simple interface will also be provided so that things that don't want to use LSB-style output (which may be the case for the LiveCD) can arbitrarily tick the progress bar without having to worry about tracking the current progress, as initramfs will keep track of this internally for you. According to ColinWastson, the LiveCD won't really want/need more than 20 or 30 ticks, so while this hack isn't ideal, it will server our purposes well for now, avoiding a usplash rewrite during a short feature implementation cycle. A simple interface will also be provided so that things that don't want to use LSB-style output (which may be the case for the LiveCD) can arbitrarily tick the progress bar without having to worry about tracking the current progress, as initramfs will keep track of this internally for you. According to ColinWatson, the LiveCD won't really want/need more than 20 or 30 ticks, so while this hack isn't ideal, it will server our purposes well for now, avoiding a usplash rewrite during a short feature implementation cycle.

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.

A simple interface will also be provided so that things that don't want to use LSB-style output (which may be the case for the LiveCD) can arbitrarily tick the progress bar without having to worry about tracking the current progress, as initramfs will keep track of this internally for you. According to ColinWatson, the LiveCD won't really want/need more than 20 or 30 ticks, so while this hack isn't ideal, it will server our purposes well for now, avoiding a usplash rewrite during a short feature implementation cycle.

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)