Those errors are non-issues.
Tear-down should, anyway, be implemented in a library to be used in
other tools like target disk mode and a stage-2 gadget utility.
Yikes, specialized code in the kexec codepath... though this is okay for
now. Let's not over-generalize when we don't know what will be required
in the future for abstraction.
This is partly complete; we need to handle the situation where **only**
stage-0 should kexec into the next system.
This is yet to be implemented, but will be done through a configuration
that transforms the current bootloader-launched stage-1 into a stage-0,
while keeping the on-disk stage-1 stage-1.
This means that we shouldn't raise an exception, but rather fail
outright. The background being black means that things *failed
successfully*, as expected.
The way we're handling them is to have a global timer that is reset at
any point a task is ran.
This gives a maximum amount of chances to any task to have its
dependencies resolve.
A minimum of 60s is given, but in reality the chances are the conditions
for trying to resolve were already present before the timeout started
counting towards that particular dependency.
Note that a long running task, when successfully ran, does not cause the
timeout to be reached.
E.g. at 10s of timeout a task is started, the loop is not executed until
the task exits. When it exits the branch followed is for a task that
ran, which means that even if the task took 70s total (which gives us 80
seconds) a timeout of 60s wouldn't apply here.
Though, please, don't make your tasks take that much time to run!
This is to ensure "UX-friendly" tasks gets run ASAP.
Quickly explained, this makes sure that the top tasks (e.g. Splash) gets
ran as soon as possible.
Given the list:
- Splash
- Graphics
- AAA
- BBB
- CCC
If `Graphics` ends up running, and AAA, BBB and CCC can too, Splash will
have to wait until all those tasks got ran once!
Not ideal for UX, if e.g. BBB takes time to *run* and we can't show the
progress to users!
The added cost of restarting the queue is minimal with tests I ran. It
was not more than a tenth of a second, and could even be rounding
errors.
