[flashrom] [PATCH][RFC] Progress bar

[Michael Karcher]

Some random thoughts about progress printing in flashrom.

Am Freitag, den 09.07.2010, 21:55 +0200 schrieb Carl-Daniel Hailfinger:
> The biggest problem is deciding which operations should print a progress
> bar.
The first thing we have to be aware of is that there are two kinds of
progress printing that seems very similar, but are in fact completely
different when you get at implementing them. Being aware of this
distinction should help answering some of the questions.

A) The first type of progress bar ist just what one naively thinks of
when one heres "progress bar", i.e. 0%=start of "operation", 100%=end of
"operation". You "just" have to define what you mean by "operation", and
how to map the steps of the operation to percentage.

B) The second type of progress bar is a "flash status map". You probably
know the kind of disk map displayed by the defragmentation tools, I mean
something like that. So we can display flash areas as "no rewrite
needed", "sucessfully flashed", "erased sucessfully", "currently
modified block" and so on, for example by different letters or colors
representing the different states.

It might turn out that in fact we want both type-A (simple UI) and
type-B (sophisticated GUI, having the status map and a type-A progress
bar) progress indication, but as far as I can see this means we have to
implement both seperately, and not have just one type of progress
indication and try to fudge the one type of output from code that calls
status updates for the other type.

> Write? Sure.
> Erase? Sure. But how do you handle a one-sector erase in the middle of
> some write operation?
One-sector-erases don't just happen in the middle of write, but they are
planned from the beginning. If you want to go to mere progress printing,
the "operation" defined above must include both erasing and writing, so
that erasing is a part of the "operation". This has the consequence that
the "current address" is not directly proportional to the progress bar
state, as the "operation" is not just doing one thing for each addresss.

If you are deciding to implement type-B address map printing, this
question of course does not apply at all.

> Read? Makes sense as well. But how do you handle the reads used for
> verification of erase/write? The two-bars problem strikes again.
Same comment as above. A "in-total" progress bar needs to consider for
each "block" (probably erase-block) the steps of "erase", "erase check",
"write", "verify" and scale the progress appropriately. Or one
recolors/overwrites "erasing" marks to "erased OK" marks.

> Another problem: How often do we call the progress bar update? Once per
> byte? Per sector? Per arbitrary unit? Will the division and
> multiplication performed on every progress bar update affect
> performance, especially on architectures where such operations are
> sloooooooooow?
Of course calling progress update per byte is nonsense. We need a bigger
unit. For some operations like mmapped reads (block copies) that are
currently implemented atomic, progress updating seems to make no sense.
Most flash operations are considerably slower than progress bar updates
(think page program, sector erase, chip erase). The only operation that
suffers from progress printing would be byte program/byte read. Maybe
even the 5-byte stuff some SPI masters have at maximum.

One approach to solve the problem of "how do we avoid much too many
multiplication/division operations" is to calculate the position of the
next change too when a change of the progress bar is printed, and ignore
all progess values (maybe addresses, but see above that addresses might
not be what we really want) below the calculated next-change point. This
avoids all calculations until needed.

Regards,
  Michael Karcher