Actions
Refactoring #418
openThree-step structure of programmer init functions
Start date:
10/09/2022
Due date:
% Done:
0%
Estimated time:
Affected versions:
Needs backport to:
Affected hardware:
Affected OS:
Description
As discussed on: https://review.coreboot.org/c/flashrom/+/68231/1/rayer_spi.c#292
[Angel]
Hmmm, does it make sense to get I/O perms before parsing programmer params?
[Edward]
That is a very good question, this maybe subjective patch though so I don't have strong feelings yet about it. However my internal reasoning was the following:
conceptual rubrics:
i) check permissions&&resource requirements are meet before doing anything,
ii) check programmer configuration before init'ing,
iii) do programmer init.
the next step based off these rubrics, or flow if you will, would be to move (i)&&(ii) into core logic and only ever enter the programmer entry once (i)&&(ii) has satisfiability.
Though I admit this patch on its own doesn't tell the above story so we could leave it for now.
[Angel]
The three steps seem reasonable, but i) and ii) seem to be in inverse order. For some programmers, the "permissions&&resource requirements" may not be fully known until the configuration has been checked.
How about:
1) validate and parse programmer configuration, before doing anything,
2) obtain required permissions and resource requirements, before init'ing,
3) do programmer init.
With the ordering suggested above, this little commit isn't needed.
[Edward]
You are correct, great insight Angel. Can we spawn a bug so this doesn't get lost? I will abandon this commit.
Updated by Felix Singer about 2 years ago
- Tracker changed from Other to Refactoring
- Target version changed from none to main
Actions