[M] Change in flashrom[master]: tree/: Move programmer_delay() out of programmer state machine
Attention is currently required from: Felix Singer, Edward O'Callaghan, Anastasia Klimchuk, Alexander Goncharov.
Nico Huber has posted comments on this change. ( https://review.coreboot.org/c/flashrom/+/67393 )
Change subject: tree/: Move programmer_delay() out of programmer state machine ......................................................................
Patch Set 5:
(1 comment)
Commit Message:
https://review.coreboot.org/c/flashrom/+/67393/comment/02c506c9_16ab8d99 PS4, Line 13:
I understand you have more longer-term ideas of modifying/improving libflashrom API. Do you think you can start a discussion about it?
The design is already set, even if not in code. There is a currently blind `struct flashrom_programmer`. Just like `flashrom_flashctx` it's supposed to provide the API user with a handle for internal state. `flashrom_flashctx` only exists once a chip was successfully probed, so we need that `flashrom_programmer` for any state handling before the probing.
Similarly, but not in the API yet, we need another handle for things before the programmer init. If you look at the first three API functions, this is visible already: flashrom_init() what is it supposed to init? what could that be but changing a state? same for flashrom_shutdown(). flashrom_set_log_callback() literally says to set a state but has no argument that would provide a state to alter.
This is also something that if implemented first, would make internal changes to rid of globals easier and clearer.
One general observation, why I believe all this has become an emotional drag: there seem to be a lot of patches lately that could be much easier done in a different order or after something else was done. This is particularly hard to change because at the same time people argue that patches should be reviewed and merged when they are written, and just because they are written. If somebody really feels everything should be merged: there are still patches around on Gerrit and patchwork (from ML review times), please start with those before writing any more patches!
-
Nico Huber (Code Review)