On 17 August 2017 at 23:19, Nico Huber <[email protected]> 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 _______________________________________________ flashrom mailing list [email protected] https://mail.coreboot.org/mailman/listinfo/flashrom
