On 2018-03-05 17:24, [ext] Andreas J. Reichel wrote:
> From: Andreas Reichel <[email protected]>
>
> If 'recovery_status' is set to 'in_progress' by the bootloader interface
> of SWUpdate, then the api sets the internal environment struct member
> called 'in_progress' to 1 by creating a new environment. However, if
> SWUpdate sets it to 'failed', then SWUpdate's bootloader interface calls
> 'ebg_env_set' with a variable name of 'recovery_status', which creates a
> user variable with that name.
> After an update process, the SWUpdate bootloader interface's unset
> function is called which must unset the 'recovery_status'. However, now
> depending on wether it was changed to 'in_progress' or 'failed' before,
> the user variable might exist or not. This logic is complex and much
> easier to implement into env_api by deleting such a user variable if it
> exists inside the finalize function.
>
> Signed-off-by: Andreas Reichel <[email protected]>
> ---
> env/env_api.c | 18 +++++++++++++++---
> 1 file changed, 15 insertions(+), 3 deletions(-)
>
> diff --git a/env/env_api.c b/env/env_api.c
> index 75695d1..bf5c7c9 100644
> --- a/env/env_api.c
> +++ b/env/env_api.c
> @@ -240,11 +240,23 @@ int ebg_env_close(ebgenv_t *e)
> return 0;
> }
>
> -int ebg_env_finalize_update(ebgenv_t *e) {
> +int ebg_env_finalize_update(ebgenv_t *e)
> +{
> if (!e->bgenv || !((BGENV *)e->bgenv)->data) {
> return EIO;
> }
> - ((BGENV *)e->bgenv)->data->in_progress = 0;
> - ((BGENV *)e->bgenv)->data->ustate = USTATE_INSTALLED;
> +
> + BG_ENVDATA *data;
> + data = ((BGENV *)e->bgenv)->data;
> + data->in_progress = 0;
> + data->ustate = USTATE_INSTALLED;
> +
> + /* Also delete any ramaining user variable called 'recovery_status' */
remaining
Giving a brief reason here again might help event more than describing
what is done below...
> + uint8_t *recv_status;
> + recv_status = bgenv_find_uservar(data->userdata, "recovery_status");
> + if (recv_status) {
> + bgenv_del_uservar(data->userdata, recv_status);
> + }
> +
> return 0;
> }
>
But doesn't that encode the behavior of one user of our API into our
API? Sounds not like I should like this. Or even merge it.
Jan
--
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux
--
You received this message because you are subscribed to the Google Groups "EFI
Boot Guard" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/efibootguard-dev/fed73870-a891-fc43-3257-01dacbc57ed5%40siemens.com.
For more options, visit https://groups.google.com/d/optout.
