Adding capture support to score

[Jennifer Averett]

The attached patches are a starting point for discussions for adding capture support
to core objects.   We started to write notes based on our discussions but the text
was harder to follow than just writing some code and commenting on it. It is hard
to see the impact of "word changes" versus real changes.

The initial cut has one method call per Score Handler with an enumerated
parameter indicating points of interest.  Most take a thread pointer and
an object id as arguments which can be interpreted based on the 
event indicated by the enumerated first argument.

Some of the items we would like to discuss:

  1) Should the number of methods be expanded to one method per point of interest?

   Having one method per "event" or doing it this way is a no-win choice. The callout 
  table will grow larger with more entries if we go to one function per event.  More
  methods will be in the capture engine. But if we stick this way, there is a smaller
  callout table, fewer capture methods, but the capture methods likely will have some
  decode logic.

  2) This design focuses on pass paths for points of interest and ignores failure paths,
      is this the direction we wish to follow?

  There are potentially LOTS of failure points and the errors will be in the supercore level.
  Worse, a "try lock" which doesn't get the mutex could end up in a busy loop swamping
   the capture engine.
    
  3) We think the callout table should be completely populated. The table is either 
    full of methods or not. It is an error not to install a handler for every event.  This
    simplified checks at run-time.

  4) We discussed having the Score own a table with stubs so the calls are always 
  present but that could negatively impact minimum footprint. This only puts a 
  single pointer and code to call. This point is arguable if we stick to the small
  number of handlers approach. Eliminating the "if table installed" check and always
  making the subroutine call to a stub MIGHT be better. But we thought avoiding
  a subroutine call in critical paths was best.

So this is basically some code using one approach for discussion purposes. It 
Is only known to compile and this may not be enough for you to compile it. :)

We want to discuss the design approach and see where to take this.

Jennifer Averett
On-Line Applications Research
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-score-core-capture-initial-start-point.patch
Type: text/x-patch
Size: 8728 bytes
Desc: 0001-score-core-capture-initial-start-point.patch
URL: <http://lists.rtems.org/pipermail/devel/attachments/20140708/adf67e2d/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0002-score-core-mutex-Add-core-capture.patch
Type: text/x-patch
Size: 5209 bytes
Desc: 0002-score-core-mutex-Add-core-capture.patch
URL: <http://lists.rtems.org/pipermail/devel/attachments/20140708/adf67e2d/attachment-0001.bin>