Re: Using libflashrom from fwupd

[Richard Hughes]

On Wed, 16 Aug 2017 at 22:02, David Hendricks  wrote:
> 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.

Dragging up an email thread from a long time ago, apologies. We're
finally using libflashrom via fwupd "in production" so to speak. One
glaring problem is that the UI "freezes" when we're doing operations
with libflashrom, which we've worked around with just making the
progress bar spin up and down so at least it looks like the program
has not crashed. Of course, the correct thing to do is return the
progress information because, as David says, some flash chips take a
looong time to write.

I've attached a patch for some initial comments, if this looks
acceptable I can add some more callbacks in other flash
implementations (as at the moment I've only covered SPI stuff) but I
didn't want to spend time on a mega patch before I had some kind of
initial thumbs-up. Comments welcome. Thanks.

Richard.

Using libflashrom from fwupd

[Edward O'Callaghan]

Hey Richard,

I like the general idea and mostly the interface however not so much
the singleton in the API. Rather, I think we should pack and carry
state within the flashctx as it is a more reentrant design that lends
well to writing unit-tests for which I would like to see more of in
Flashrom. Flashrom suffers from way too many singletons and lack of
test coverage so it would be good to steer things towards the
direction of reentrant logical units of code with corresponding
unit-tests written, the testing framework is already merged so I would
invite you to write a test with the additional API if you could?

Please feel free to add me as a reviewer to your series and let's make
it happen!
Kind Regards,
Edward.

On Fri, 15 Jan 2021 at 20:57, Richard Hughes  wrote:
> On Wed, 16 Aug 2017 at 22:02, David Hendricks  wrote:
> > 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.
>
> Dragging up an email thread from a long time ago, apologies. We're
> finally using libflashrom via fwupd "in production" so to speak. One
> glaring problem is that the UI "freezes" when we're doing operations
> with libflashrom, which we've worked around with just making the
> progress bar spin up and down so at least it looks like the program
> has not crashed. Of course, the correct thing to do is return the
> progress information because, as David says, some flash chips take a
> looong time to write.
>
> I've attached a patch for some initial comments, if this looks
> acceptable I can add some more callbacks in other flash
> implementations (as at the moment I've only covered SPI stuff) but I
> didn't want to spend time on a mega patch before I had some kind of
> initial thumbs-up. Comments welcome. Thanks.
>
> Richard.
> _______________________________________________
> flashrom mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]

Using libflashrom from fwupd

[Richard Hughes]

On Sun, 17 Jan 2021 at 03:55, Edward O'Callaghan  wrote:
> I think we should pack and carry state within the flashctx

Yes, good idea.
> the testing framework is already merged so I would
> invite you to write a test with the additional API if you could?

Aha! I did not know of the unit test existence, apologies. I've never
used cmocka before, but I gave it a go, reviews most welcome:
https://review.coreboot.org/c/flashrom/+/49643

If that looks acceptable I can also add progress reporting to some of
the other programmers too.

Richard.