On Tue, Aug 15, 2017 at 4:55 AM, Richard Hughes <hughsi...@gmail.com> wrote:
> Hi all, > > I'm the maintainer of fwupd, which is a daemon for doing firmware > updates in Linux. Using fwupd about 200,000 people update firmware > every month. At the moment I have an out-of-tree patch to use the > flashrom CLI for updating coreboot on Purism laptops, which exec's a > flashrom binary with the correct arguments and then screen scrapes the > output. This is less than ideal. I saw the appearance of a libflashrom > in the staging branch and got very excited. I'm assuming the long term > goal here is to install a shared with stable API/ABI library and a > pkg-config file. If so, please keep reading. > > One thing that is really important for fwupd is progress completion; > as flashing the firmware is an inherently scary thing to do users do > like to see a progress bar move from 0% to 100% in a gradual way as > it's very re-assuring. This is even more important for the GUI, where > people that just see a spinner don't know if the process is going to > take 10 seconds, or 10 minutes. > Agreed! Especially since a lot of users have large chips, slow programmers, or sometimes both. Simple read operations can take a worryingly long time on some common hardware these days. > > Would it be possible to have a process callback for > flashrom_image_read(), flashrom_image_write() and > flashrom_image_verify()? It'd need to have some kind of callback > userdata too, for instance: > > int flashrom_image_verify(struct flashrom_flashctx *, const void > *buffer, size_t buffer_len, flashrom_progress_callback callback_fn, > void *callback_user_data); > > and also: > > typedef void(flashrom_progress_callback)(uint64 completed, unit64 > total, void *user_data) > The short answer is yes. Nico also briefly mentioned an idea on IRC to use a mechanism similar to flashrom_set_log_callback() to avoid complicating function signatures for the read, write, and verify functions. > > I'm not familiar at all with flashrom internals, but could try to > produce a patch if required -- although to propagate the progress > through operations would mean patching a lot of chip->read() callbacks > which probably requires a more experienced hand. Ideas welcome, > thanks. > > Richard. > > _______________________________________________ > flashrom mailing list > flashrom@flashrom.org > https://mail.coreboot.org/mailman/listinfo/flashrom >
_______________________________________________ flashrom mailing list flashrom@flashrom.org https://mail.coreboot.org/mailman/listinfo/flashrom