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 hughsient@gmail.com wrote:
On Wed, 16 Aug 2017 at 22:02, David Hendricks david.hendricks@gmail.com 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 -- flashrom@flashrom.org To unsubscribe send an email to flashrom-leave@flashrom.org