On 17 August 2017 at 23:19, Nico Huber nico.h@gmx.de wrote:
typedef void(flashrom_progress_event_cb)(enum flashrom_progress_event event, char *reason, void *user_data);
`char *reason`? see above.
I use libraries with const char* enums; and although it makes it easy to add states the calling program never knows what to expect -- "add" or "ADD", "add foo" or "add: foo" -- I'd really much prefer this to be tightly controlled with an enum.
In a simplified version (let's assume resets don't count), we could simply approximate everything with the size of the flash chip (or size of included regions if a layout is used). So total amount of progress for a read/write/verify would be three times the size. Read and verify would be linear, write rather bumpy, but does it matter?
I think it's fine.
Richard, would it be feasible for your GUI visualization if you'd do the steps separately? e.g. you could make a backup, then you could pass the backup back to libflashrom together with the new data to be written (which would allow us to skip the usual read before write) and then finally call a function to verify everything.
So, that's ok, on the assumption we know what to do -- perhaps not all chips need erasing...
So basically you'd have three calls into libflashrom which take some time and would show three times a progress bar. If you wanted to show a total progress you'd have to do that manually then.
libflashrom would be called by fwupd, which would then proxy on a percentage to the GUI, so I think it's fine that fwupd can control what's happening. That's pretty much what it does for the other userspace flash plugins.
Richard