Attention is currently required from: Felix Singer, Richard Hughes, Edward O'Callaghan, Angel Pons, Daniel Campello, Anastasia Klimchuk.

View Change

1 comment:

• File include/libflashrom.h:

  • Patch Set #2, Line 85: typedef void(flashrom_progress_callback)(struct flashrom_flashctx *flashctx);

    Nico, if we understand you correctly, flashctx should be kept internal, and the API should have a di […]

    Yes about `flashctx`. But with `user_data` I mean the generic (opaque) object passed
    around as void pointer. This is a common concept for callback functions. Beside the
    function, the API user passes any information that it likes to associate with the
    callback function calls. The implementation behind the API, that calls the callback,
    has no idea about this data, hence just a void pointer, no struct.

    The `flashctx` may or may not be needed by the callback as well. We can either
    have it as parameter (which would probably be unused by callback implementations),
    or let the API user handle it: they already have it, and can store it in their
    `user_data` object if needed, or have things simple if they don't need it.

    Quite generally, I think these APIs are best to be discussed with their users
    (to reach a reasoable dependency inversion [1]). Looking at [2] for instance,
    I see no need for `flashctx`. Other use cases may differ, though.

    [1] https://en.wikipedia.org/wiki/Dependency_inversion_principle (not necessarily
    worth reading more than the basic idea)
    [2] https://github.com/fwupd/fwupd/pull/4675

To view, visit change 64663. To unsubscribe, or for help writing mail filters, visit settings.