lp://staging/~johill-lanl/epics-base/server2

Branch merges

Propose for merging

No branches dependent on this one.

Related source package recipes

No recipes using this branch. (?)

Create packaging recipe

Related snap packages

Related bugs

Related blueprints

13178. By Jeff Hill 101150 <email address hidden> on 2021-11-19

made the -s flag work correctly

13177. By Jeff Hill 101150 <email address hidden> on 2021-11-17

fixed realloc warning found by static analysis
(looking at this code I doubt that it works, and also
it doesnt appear to be called by anything in base)

13176. By Jeff Hill 101150 <email address hidden> on 2021-11-17

fixed memory leak found by static analysis

13175. By Jeff Hill 101150 <email address hidden> on 2021-11-17

initialized file pointer variable to fix compiler warning

13174. By Jeff Hill 101150 <email address hidden> on 2021-11-17

added parenthesis around macro definition to avoid unexpected
order of operations identified by comnpiler warnings

13173. By Jeff Hill 101150 <email address hidden> on 2021-11-17

removed READONLY, its nolonger used

13172. By Jeff Hill 101150 <email address hidden> on 2021-11-17

In the past, the RTEMS epicsThreadGetPriority function relied on a feature of the
 system call rtems_task_set_priority to query the priority as follows.

 rtems_task_set_priority (tid, RTEMS_CURRENT_PRIORITY, &pri)

 However, the priority received by this feature is the RTEMS
 "current" priority which, after referencing the RTEMS source
  code, appears to reflect the current priority in the scheduling
  system including side effects from priority inheritance, and is
 _not_ the as-requested RTEMS "real" priority.

  Maybe up to RTEMS 4.11+ (just before RTEMS 5) there is no system
  call to query the "real" priority as specified when creating the
  thread, and or requesting a new thread priority. In RTEMS 5 I see
  that there is a new rtems_task_get_priority call. I dont know if
  it returns the "real" or the "current" priority.

  We need to return the "real" priority because the ca context is
  offset off of the current thread's as-specified priority, and
  the current "priority" is inappropriate, very unreliably spasmodic,
  for use in any end user context other than for diagnostic output.

Also fixed an issue where the task internals show method could return
witout renabling dispatch

13171. By Jeff Hill 101150 <email address hidden> on 2021-11-17

o backed out most of revision 13164 because my conclusions about
strange CAC thread priorities I have seen are incorrect, and the
decision to postpone thread creation until creation of the first
channel appears to be well advised.
o made the m_initializingThreadsPriority data member of class cac
a constant data member

13170. By Jeff Hill 101150 <email address hidden> on 2021-11-16

change to raw mode from cooked mode only when RTEMS 'top' command is running

13169. By Jeff Hill 101150 <email address hidden> on 2021-11-16

Addetd RTEMS specific "top" and "stackuse" shell commands. Im not certain that "top" will persist in future versions of RTEMS.