Introduction of Priority_node structure (priority.h)

Mon May 11 15:40:37 UTC 2020

On Mon, May 11, 2020 at 9:27 AM Gedare Bloom <gedare at rtems.org> wrote:
>
> On Mon, May 11, 2020 at 2:54 AM Heinz Junkes <junkes at fhi-berlin.mpg.de> wrote:
> >
> > The Priority_node structure was committed to the 4.10 branch of RTEMS in December
> > 2017 (78b867e26d score: replace current and real priority with priority node).
> >
> > Do I have a possibility to know at  compile time (in our case  EPICS) if it is present or not.
> >
> > Background:
> > We had received the following bug report:
> >
> > > On 1/16/19 2:51 PM, Michael Westfall via Tech-talk wrote:
> > >> When compiling base R3.14.12.7 for RTEMS 4.10.2, I get the following error:
> > >>
> > >> /gem_swdev1/targetOS/RTEMS/rtems-4.10/bin/powerpc-rtems4.10-gcc --pipe -B/gem_swdev1/targetOS/RTEMS/rtems-4.10/powerpc-rtems4.10/beatnik/lib/ -specs bsp_specs -qrtems   -fasm -c   -mcpu=7400 -D__ppc_generic                   -DUNIX      -O2 -g -g   -Wall       -DMY_DO_BOOTP=NULL -DHAVE_MOTLOAD -DRTEMS_NETWORK_CONFIG_MBUF_SPACE=2048 -DRTEMS_NETWORK_CONFIG_CLUSTER_SPACE=5120     -MMD -I. -I../O.Common -I. -I../../../src/libCom/osi/os/RTEMS -I../../../src/libCom/osi/os/posix -I../../../src/libCom/osi/os/default -I.. -I../../../src/libCom/bucketLib -I../../../src/libCom/ring -I../../../src/libCom/calc -I../../../src/libCom/cvtFast -I../../../src/libCom/cppStd -I../../../src/libCom/cxxTemplates -I../../../src/libCom/dbmf -I../../../src/libCom/ellLib -I../../../src/libCom/env -I../../../src/libCom/error -I../../../src/libCom/fdmgr -I../../../src/libCom/freeList -I../../../src/libCom/gpHash -I../../../src/libCom/iocsh -I../../../src/libCom/logClient -I../../../src/libCom/macLib -I../../../src/libCom/misc -I../../../src/libCom/osi -I../../../src/libCom/taskwd -I../../../src/libCom/timer -I../../../src/libCom/tsDefs -I/gem_swdev1/epics/R3.14.12.7/base/include/os/RTEMS -I/gem_swdev1/epics/R3.14.12.7/base/include         ../../../src/libCom/osi/os/RTEMS/osdThread.c
> > >> ../../../src/libCom/osi/os/RTEMS/osdThread.c: In function 'showInternalTaskInfo':
> > >> ../../../src/libCom/osi/os/RTEMS/osdThread.c:617: error: 'Thread_Control' has no member named 'real_priority'
> > >> ../../../src/libCom/osi/os/RTEMS/osdThread.c:624: error: 'Thread_Control' has no member named 'current_priority'
> > >> ../../../src/libCom/osi/os/RTEMS/osdThread.c:624: error: 'Thread_Control' has no member named 'real_priority'
> > >> ../../../src/libCom/osi/os/RTEMS/osdThread.c:625: error: 'Thread_Control' has no member named 'current_priority'
> > >> ../../../src/libCom/osi/os/RTEMS/osdThread.c:627: error: 'Thread_Control' has no member named 'real_priority'
> > >> ../../../src/libCom/osi/os/RTEMS/osdThread.c:627: error: 'Thread_Control' has no member named 'current_priority'
> > >> make[3]: *** [osdThread.o] Error 1
> > >> make[3]: Leaving directory `/gem_swdev1/epics/R3.14.12.7/epics-base-R3.14.12.7/src/libCom/O.RTEMS-beatnik'
> > >> make[2]: *** [install.RTEMS-beatnik] Error 2
> > >> make[2]: Leaving directory `/gem_swdev1/epics/R3.14.12.7/epics-base-R3.14.12.7/src/libCom'
> > >> make[1]: *** [libCom.install] Error 2
> > >> make[1]: Leaving directory `/gem_swdev1/epics/R3.14.12.7/epics-base-R3.14.12.7/src'
> > >> make: *** [src.install] Error 2
> >
> > I fixed it with this patch:
> > > diff --git a/modules/libcom/src/osi/os/RTEMS/osdThread.c b/modules/libcom/src/osi/os/RTEMS/osdThread.c
> > > index 769e958..2db1ca5 100644
> > > --- a/modules/libcom/src/osi/os/RTEMS/osdThread.c
> > > +++ b/modules/libcom/src/osi/os/RTEMS/osdThread.c
> > > @@ -640,17 +640,17 @@ showInternalTaskInfo (rtems_id tid)
> > >       * that priority should be displayed, not the value truncated to
> > >       * the EPICS range.
> > >       */
> > > -    epicsPri = 199-thread.real_priority;
> > > +    epicsPri = 199-thread.Priority_node.real_priority;
> > >      if (epicsPri < 0)
> > >          fprintf(epicsGetStdout(),"   <0");
> > >      else if (epicsPri > 99)
> > >          fprintf(epicsGetStdout(),"  >99");
> > >      else
> > >          fprintf(epicsGetStdout()," %4d", epicsPri);
> > > -    if (thread.current_priority == thread.real_priority)
> > > -        fprintf(epicsGetStdout(),"%4d    ", (int)thread.current_priority);
> > > +    if (thread.Priority_node.current_priority == thread.Priority_node.real_priority)
> > > +        fprintf(epicsGetStdout(),"%4d    ", (int)thread.Priority_node.current_priority);
> > >      else
> > > -        fprintf(epicsGetStdout(),"%4d/%-3d", (int)thread.real_priority, (int)thread.current_priority);
> > > +        fprintf(epicsGetStdout(),"%4d/%-3d", (int)thread.Priority_node.real_priority, (int)thread.Priority_node.current_priority);
> > >      showBitmap (bitbuf, thread.current_state, taskState);
> > >      fprintf(epicsGetStdout(),"%8.8s", bitbuf);
> > >      if (thread.current_state & (STATES_WAITING_FOR_SEMAPHORE |
> > >
> >
> > But now it turned out that there was also a 4.10.2  variant in which the priority_node structure did not yet exist:
> >
> > Andrew Johnson wrote
> > | finally took a proper look at this bug report.
> >
> > The APS has been using RTEMS 4.10.2 since 2013 (4.10.2 was tagged on
> > 2011-12-13, I built it in December 2012) and our headers do *not* have
> > this change, which was committed to the 4.10 branch of RTEMS in December
> > 2017 (78b867e26d score: replace current and real priority with priority
> > node).
> >
> > Merging this particular change would thus break EPICS builds here at
> > APS, and unfortunately it doesn't look like there's an easy way to
> > detect the change at compile-time. Until someone can work out how to do
> > that I can't accept this patch into the Base 3.15 or 7.0 branches.
> >
>
> Does rtems_task_set_priority(thread, 0, &current_priority); work?
>
> That will get the current_priority field at least. I don't know if
> there is a way to get the real_priority value from the public APIs.
>
The real_priority should only change if explicitly requested by user
though, so if it is needed just keep track of it in epics when
creating threads or changing their priority (if that is done)?

>
> Since they're already deep in the score, maybe check the sizeof(struct
> Thread_Control_struct), they should be different between the released
> 4.10.2 version and 4.10 head, To avoid the compiler error, use pointer
> arithmetic to get at the field that represents the current priority.
> It isn't pretty, but it would probably work.
>
> > Heinz
> >
> >
> > _______________________________________________
> > devel mailing list
> > devel at rtems.org
> > http://lists.rtems.org/mailman/listinfo/devel