# 14th July 2022, 6:00 - 7:00 UTC+0
Attendees: Felix, Thomas, Edward, Anastasia
## Decisions Summary
* aklm will be creating unit tests from selfchecks. Selfchecks will
stay for now, because they are covering all platforms and unit tests do
not [yet]. In the long-term, we want unit tests working on all
platforms and then we can remove the selfchecks
* We had impromptu in-depth discussions about the future of core
elements of flashrom, e.g. board-enable infrastructure or how flash
chips are organized, and this may turn into future projects.
## Agenda
* Maintainers file;
* Thomas agrees we should try the mechanism but suggests it may be
overkill for the project.
* Thomas suggests that every flashrom developer is responsible for
the whole tree.
* Quasisec - Maintainers file does not preclude flashrom developers
or block them from one another, simply to;
* Allow new developers know who could be a good reviewer,
* Critical developers are aware of patches to drivers that
impact them (e.g., secunet knows a ichspi patch is up for review).
* Quasisec - Not unlike the Linux kernel there are both subtree
maintainers and every individual developer is responsible for entire
tree changes when an internal API changes.
* Global state;
* Quasisec - One of the first projects for aklm was to remove
static globals per driver.
* Quasisec - Sent patches to help move the pacc global state
inwards.
* Quasisec - libflashrom has something aspirational but was
probably merged prematurely that would allow for a state machine with a
scope that is longer than the per-driver life-time of `flashctx`.
* This per-flashrom instance context needs to be worked out by
taking global statics out of flashrom.c into a struct to form the basis
of this state machine.
* Also, super i/o artifacts scattered everywhere should be
consolidated into a flashrom super i/o support library.
* Pacc global state needs to be polished off and folded into
the per-flashrom instance context as well.
* Quasisec - Finally cli_classic can likely be hoisted upon
libflashrom completely.
* Quasisec - It would be nice to move in a general direction of
less OOP huge singleton contexts.
* Self-check vs unit-tests;
* [aklm] How about turning flashrom.c#selfcheck() into unit test(s)
? I can look into that. For example, testing the order of erase
functions would be great to do when a patch is pushed to gerrit.
* Unit tests are helpful for developers,
* Runtime sanity self-testing is perhaps too late.
* Blocker - unit tests only work on Linux at the moment.
* Thomas agrees it's better for them to be in the unit-test.
* Good starting point is to convert sanity checks to unit tests and
later we can switch.
* As a first step we can have unit tests AND selfcheck, because
unit tests run for Linux only, other systems rely on selfcheck(). TODO
aklm
* Re-write as proper unit tests, small and granular.
* There is also selfcheck_board_enables in board_enable!
* Quasisec - Speculative here but can a first step be to factor
out all self-checks into selfcheck.c and _maybe then_ next step is to
not compile on Linux as it has unit-tests ?
* Quasisec / Thomas;
* Long term projection into the future of what flashrom could look
like.
* Less OOP
* Have flashrom core the ability to query programmer capabilities
and query flashchip capabilities. If the user requests an operation X
then flashrom core can do the NxM and determine what to do rather than
hard coded bespoke decisions.
_______________________________________________
flashrom mailing list -- flashrom@flashrom.org
To unsubscribe send an email to flashrom-le...@flashrom.org
