Ok, thanks.
On Thu, Jul 16, 2020 at 11:54 PM Christian Mauderer
<christian.maude...@embedded-brains.de> wrote:
>
> Hello Gedare,
>
> thanks for the review.
>
> On 17/07/2020 07:43, Gedare Bloom wrote:
> > On Thu, Jul 9, 2020 at 2:21 AM Christian Mauderer
> > <christian.maude...@embedded-brains.de> wrote:
> >>
> >> This adds the possibility to request a retry in the media-listener if an
> >> operation failed. Usefull for example if you want to automatically
> >> reformat a disk if it wasn't possible to mount it.
> >> ---
> >> cpukit/include/rtems/media.h | 3 +++
> >> cpukit/libblock/src/media.c | 29 ++++++++++++++++-------------
> >> 2 files changed, 19 insertions(+), 13 deletions(-)
> >>
> >> diff --git a/cpukit/include/rtems/media.h b/cpukit/include/rtems/media.h
> >> index b2a3e2dc91..db13664975 100644
> >> --- a/cpukit/include/rtems/media.h
> >> +++ b/cpukit/include/rtems/media.h
> >> @@ -281,6 +281,9 @@ typedef enum {
> >> *
> >> * @retval RTEMS_SUCCESSFUL Successful operation.
> >> * @retval RTEMS_IO_ERROR In the inquiry state this will abort the action.
> >> + * @retval RTEMS_INCORRECT_STATE In the failed state this will cause a
> >> retry.
> >> + * Make sure to have a retry counter or similar to avoid endless loops if
> >> you
> >> + * use this this value.
> > delete one 'this'
> >
> > Glad you have this comment, that was my first thought when I read the
> > commit msg.
> >
> >> */
> >> typedef rtems_status_code (*rtems_media_listener)(
> >> rtems_media_event event,
> >> diff --git a/cpukit/libblock/src/media.c b/cpukit/libblock/src/media.c
> >> index 5b2b06b5b2..c00825587c 100644
> >> --- a/cpukit/libblock/src/media.c
> >> +++ b/cpukit/libblock/src/media.c
> >> @@ -420,26 +420,29 @@ static rtems_status_code process_event(
> >> )
> >> {
> >> rtems_status_code sc = RTEMS_SUCCESSFUL;
> >> + rtems_status_code sc_retry = RTEMS_SUCCESSFUL;
> >> rtems_media_state state = RTEMS_MEDIA_STATE_FAILED;
> >> char *dest = NULL;
> >>
> >> - sc = notify(event, RTEMS_MEDIA_STATE_INQUIRY, src, NULL);
> >> - if (sc == RTEMS_SUCCESSFUL) {
> >> - state = RTEMS_MEDIA_STATE_READY;
> >> - } else {
> >> - state = RTEMS_MEDIA_STATE_ABORTED;
> >> - }
> >> -
> >> - sc = (*worker)(state, src, &dest, worker_arg);
> >> - if (state == RTEMS_MEDIA_STATE_READY) {
> >> + do {
> >> + sc = notify(event, RTEMS_MEDIA_STATE_INQUIRY, src, NULL);
> >> if (sc == RTEMS_SUCCESSFUL) {
> >> - state = RTEMS_MEDIA_STATE_SUCCESS;
> >> + state = RTEMS_MEDIA_STATE_READY;
> >> } else {
> >> - state = RTEMS_MEDIA_STATE_FAILED;
> >> + state = RTEMS_MEDIA_STATE_ABORTED;
> >> + }
> >> +
> >> + sc = (*worker)(state, src, &dest, worker_arg);
> >> + if (state == RTEMS_MEDIA_STATE_READY) {
> >> + if (sc == RTEMS_SUCCESSFUL) {
> >> + state = RTEMS_MEDIA_STATE_SUCCESS;
> >> + } else {
> >> + state = RTEMS_MEDIA_STATE_FAILED;
> >> + }
> >> }
> >> - }
> >>
> >> - notify(event, state, src, dest);
> >> + sc_retry = notify(event, state, src, dest);
> >> + } while (state == RTEMS_MEDIA_STATE_FAILED && sc_retry ==
> >> RTEMS_INCORRECT_STATE);
> > line length
> >
> > How do you use a retry counter? It's not obvious to me, but this is
> > not an area I work with much.
> >
>
> The retry is only done if explicitly requested by the media listener.
> The media listener is a software provided by the user. If the user
> requests a retry he should also decide how often he wants to retry the
> operation.
>
> A possibility to add a retry counter is to use the user specifiable
> argument of the media listener. The user can provide a pointer to some
> own data structure where the retries are counted.
>
> I think the retries in general are a quite exotic feature. Like my
> comment suggests I used it to try a mount for an on-board memory, if it
> doesn't work I format the disk and retry the mount.
>
> Best regards
>
> Christian
>
> >> remember_event(event, state, src, dest);
> >>
> >> if (state == RTEMS_MEDIA_STATE_SUCCESS) {
> >> --
> >> 2.26.2
> >>
> >> _______________________________________________
> >> devel mailing list
> >> devel@rtems.org
> >> http://lists.rtems.org/mailman/listinfo/devel
>
> --
> --------------------------------------------
> embedded brains GmbH
> Herr Christian Mauderer
> Dornierstr. 4
> D-82178 Puchheim
> Germany
> email: christian.maude...@embedded-brains.de
> Phone: +49-89-18 94 741 - 18
> Fax: +49-89-18 94 741 - 08
> PGP: Public key available on request.
>
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
