| Message ID | 1554195113-25525-1-git-send-email-awais_belal@mentor.com |
|---|---|
| State | Changes Requested |
| Headers | show |
| Series | client: run post-update actions | expand |
Hi Awais, On Tuesday, 2 April 2019 19:52:16 UTC+11, Awais Belal wrote: > > This runs the ipc_postupdate hook if the update succeeds > and complies with how other update mechanisms work. > > Signed-off-by: Awais Belal <awais...@mentor.com <javascript:>> > --- > tools/client.c | 10 +++++++++- > 1 file changed, 9 insertions(+), 1 deletion(-) > > diff --git a/tools/client.c b/tools/client.c > index 6dd378c..a3a0b33 100644 > --- a/tools/client.c > +++ b/tools/client.c > @@ -79,7 +79,8 @@ static int printstatus(ipc_message *msg) > > /* > * this is called at the end reporting the status > - * of the upgrade > + * of the upgrade and running any post-update actions > + * if successful > */ > static int end(RECOVERY_STATUS status) > { > @@ -89,6 +90,13 @@ static int end(RECOVERY_STATUS status) > status == FAILURE ? "*failed* !" : > "was successful !"); > > + if (status == SUCCESS) { > + printf("Update successful, executing post-update > actions.\n"); > + ipc_message msg; > + if (ipc_postupdate(&msg) != 0) > I'm currently using the client utility for testing and don't really want the post-update actions to run for each test run. What do you think about adding a command line option to either opt-in or opt-out of the post update actions? > + printf("Running post-update failed!\n"); > + } > + > pthread_mutex_unlock(&mymutex); > > return 0; > -- > 2.7.4 > > Regards Austin
Hi Austin, > > I'm currently using the client utility for testing and don't really want the post-update actions to run for each test run. > Shouldn't you simply not provide the -p option while invoking the server if that's the case? :) As I've wrote in the commit message as well if we don't do this the client's behavior is currently different from how hawkbit/mongoose would work. Shouldn't all the update mechanisms including the client work in the similar manner? > > What do you think about adding a command line option to either opt-in or opt-out of the post update actions? Not a bad option but the library already supports this so the server should be invoked without -p if that's what is needed. Am I missing something here? BR, Awais
On 03/04/19 03:01, 'Austin Phillips' via swupdate wrote: > Hi Awais, > > On Tuesday, 2 April 2019 19:52:16 UTC+11, Awais Belal wrote: > > This runs the ipc_postupdate hook if the update succeeds > and complies with how other update mechanisms work. > > Signed-off-by: Awais Belal <awais...@mentor.com <javascript:>> > --- > tools/client.c | 10 +++++++++- > 1 file changed, 9 insertions(+), 1 deletion(-) > > diff --git a/tools/client.c b/tools/client.c > index 6dd378c..a3a0b33 100644 > --- a/tools/client.c > +++ b/tools/client.c > @@ -79,7 +79,8 @@ static int printstatus(ipc_message *msg) > > /* > * this is called at the end reporting the status > - * of the upgrade > + * of the upgrade and running any post-update actions > + * if successful > */ > static int end(RECOVERY_STATUS status) > { > @@ -89,6 +90,13 @@ static int end(RECOVERY_STATUS status) > status == FAILURE ? "*failed* !" : > "was successful !"); > > + if (status == SUCCESS) { > + printf("Update successful, executing post-update > actions.\n"); > + ipc_message msg; > + if (ipc_postupdate(&msg) != 0) > > > I'm currently using the client utility for testing and don't really want > the post-update actions to run for each test run. > I do not want to see this, too. Let me also to better explain. The postupdate command is foreseen when SWUpdate runs and performs an update alone, and it must be instructed what it must do after a successful installation. When the update is triggered by an external process like the client, it has already the control. The client could also run directly the postupdate command without asking SWUpdate to do this. > What do you think about adding a command line option to either opt-in or > opt-out of the post update actions? Ok - if this is configurable (default: off) via a command line option, patch could be merged. Best regards, Stefano Babic > > > + printf("Running post-update failed!\n"); > + } > + > pthread_mutex_unlock(&mymutex); > > return 0; > -- > 2.7.4 > > > Regards > Austin > > *IMPORTANT NOTE. *If you are NOT AN AUTHORISED RECIPIENT of this e-mail, > please contact Planet Innovation by return e-mail or by telephone on > +61-3-9945 7510. In this case, you should not read, print, re-transmit, > store or act in reliance on this e-mail or any attachments, and should > destroy all copies of them. This e-mail and any attachments are > confidential and may contain legally privileged information and/or > copyright material. You should only re-transmit, distribute or > commercialise the material if you are authorised to do so. Although we > use antimalware, we disclaim any liability for any malware in any > message or attachment. This notice should not be removed. > > ** > > -- > You received this message because you are subscribed to the Google > Groups "swupdate" group. > To unsubscribe from this group and stop receiving emails from it, send > an email to swupdate+unsubscribe@googlegroups.com > <mailto:swupdate+unsubscribe@googlegroups.com>. > To post to this group, send email to swupdate@googlegroups.com > <mailto:swupdate@googlegroups.com>. > For more options, visit https://groups.google.com/d/optout.
On 03/04/19 09:37, awais.belal@gmail.com wrote: > Hi Austin, > >> >> I'm currently using the client utility for testing and don't really want the post-update actions to run for each test run. >> > > Shouldn't you simply not provide the -p option while invoking the server if that's the case? :) No, it is broken - and there are cases where -p is set (to enable the "restart" in Website), but it is not automatically done. I see that "cleint -h" is currently broken (better : it is not implemented). > As I've wrote in the commit message as well if we don't do this the client's behavior is currently different from how hawkbit/mongoose would work. Shouldn't all the update mechanisms including the client work in the similar manner? I have projects where the customer asks to update from different interfaces (so local / remote /suricatta are enabled and working), but the behavior at the end is different. It must be configurable, at run time with a command line parameter is better. This change breaks at least a copule of projects of mine. Anyway, the "client" is just an example. In many cases, this code is integrated into customer's application and the application decides what must be done. > >> >> What do you think about adding a command line option to either opt-in or opt-out of the post update actions? > > Not a bad option but the library already supports this so the server The library supports this letting the caller the possibility to call it or not. You are forcing that it is called always. >should be invoked without -p if that's what is needed. Am I missing something here? See above, there are many use cases. Best regards, Stefano Babic
diff --git a/tools/client.c b/tools/client.c index 6dd378c..a3a0b33 100644 --- a/tools/client.c +++ b/tools/client.c @@ -79,7 +79,8 @@ static int printstatus(ipc_message *msg) /* * this is called at the end reporting the status - * of the upgrade + * of the upgrade and running any post-update actions + * if successful */ static int end(RECOVERY_STATUS status) { @@ -89,6 +90,13 @@ static int end(RECOVERY_STATUS status) status == FAILURE ? "*failed* !" : "was successful !"); + if (status == SUCCESS) { + printf("Update successful, executing post-update actions.\n"); + ipc_message msg; + if (ipc_postupdate(&msg) != 0) + printf("Running post-update failed!\n"); + } + pthread_mutex_unlock(&mymutex); return 0;
This runs the ipc_postupdate hook if the update succeeds and complies with how other update mechanisms work. Signed-off-by: Awais Belal <awais_belal@mentor.com> --- tools/client.c | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-)