Attention is currently required from: Anastasia Klimchuk, Daniel Campello, Edward O'Callaghan, Nico Huber, Richard Hughes.
1 comment:
File tests/chip.c:
Patch Set #6, Line 86: struct progress_user_data *progress_user_data = progress_state->user_data;
> Redefining the callback would be ideal (void(flashrom_progress_callback)(enum flashrom_progress s […]
I don't think we can change the API without either doing a whole ABI break (increment the soname or something) or using a new function name. I haven't been able to find any external users of `flashrom_set_progress_callback`, but if any exist then changing the ABI while reusing the same function name would cause crashes in any programs built against an old header but running with a new .so.
`flashrom_set_progress_callback` needs to maintain the same API it currently has to maintain binary compatibility, but we could rename things in the header if the current structures were also renamed. Concretely, something like this should be safe:
```
// Renamed struct flashrom_progress
struct flashrom_progress_v0 {
enum flashrom_progress_stage stage;
size_t current;
size_t total;
void *user_data;
} __attribute__((deprecated));
// Renamed flashrom_progress_callback
typedef void(flashrom_progress_callback_v0)(/* omitted for brevity */)
__attribute__((deprecated));
// Obsolete function with same ABI as before.
// Implementation could be a stub.
void flashrom_set_progress_callback(
struct flashrom_flashctx *const flashctx,
flashrom_progress_callback_v0 *progress_callback,
struct flashrom_progress_v0 *progress_state,
) __attribute__((deprecated("Use flashrom_set_progress_callback_v1 instead")));
// New function with warts fixed.
void flashrom_set_progress_callback_v1(/* omitted for brevity */);
```
To view, visit change 64663. To unsubscribe, or for help writing mail filters, visit settings.