Attention is currently required from: Felix Singer, Edward O'Callaghan, Anastasia Klimchuk, Alexander Goncharov.
1 comment:
Commit Message:
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!
To view, visit change 67393. To unsubscribe, or for help writing mail filters, visit settings.