Hello Artur,
On 10/24/18 12:57 PM, artur.raglis@3mdeb.com wrote:
We would like to contribute to the flashrom project by adding missing libflashrom features like queries, proper flashrom_shutdown etc.
sounds great. ;)
Until now, I have implemented and tested missing libflashrom functions from query section [https://www.flashrom.org/Libflashrom] (based on patches from Łukasz Dmitrowski [https://patchwork.coreboot.org/patch/4316/]). There are 2 ways to get required information (e.g. supported programmers):
const char **flashrom_supported_programmers(void); //#1 int flashrom_supported_programmers(const char **supported_programmers); //#2
I suppose that returning function status (#2) is not necessary with query functions, so I'll stick to the first approach.
Please just push patches early to Gerrit (see [1]). Makes it easier to discuss interface design.
What we want to accomplish is remote firmware updates for brand new platforms straight from the factory. To do so, libflashrom will be integrated with fwupd which would control all required lib resources. I have read the conversation in the https://www.mail-archive.com/flashrom@flashrom.org/msg13518.html from which it appears that process callbacks for the progress bar is still high priority task.
Well, it's a task. Nothing has high priority here as nobody is directly paid for flashrom work. I would be happy to review patches for that, too (if they implement what I suggested back then, I hope; not sure, if not). :)
Are there any new ideas / hints that we need to know for further development?
Mostly, what Richard already mentioned: The lack of context pointers in parts of the API. Basically what I wrote here [2]. Regarding the (then three) different kinds of context, the current flags mechanism (enum flashrom_flag) should be replaced with per context options that one can set (everything that can be set on the command line currently would need some abstraction). Maybe not a pair of ID|bool but instead a pair of ID|void* and the actual programmer (or chip) implementation could decide how that is interpreted based on the ID.
Unification of error codes is another concern. Would make it easier to provide error strings. Though, the current log callback mechanism already provides a lot of flexibility (e.g. you could capture all the level `error` messages during execution of one procedure and show them if something went wrong).
Layout handling is another thing that needs improvement but that also requires internal restructuring. But... maybe we should start with the API and implement it later.
Nico
[1] https://coreboot.org/Git [2] https://www.mail-archive.com/flashrom@flashrom.org/msg13532.html