Capture Engine - Addition of capture task information to the capture buffer

[Joel Sherrill]

On 9/4/2014 9:28 PM, Chris Johns wrote:
> On 5/09/2014 4:00 am, Joel Sherrill wrote:
>> Piling on... most of the information in the capture engine's task
>> control blocks can be logged statically on task create.
> This should be done when the first reference to the task is logged. The 
> task may already exist.
Based on the discussion below, I think we can address this in the
TCB. A first seen flag.

We can pursue this and see where it leads. We can compress the
representation of the information but it has to go somewhere and
we can't use the pool of capture task control records anymore.
>> BUT... there is also trigger information
>> in there. Where should that be now?
> The current trigger information is design around the "task" because the 
> events are per task. We think we may need a different trigger mechanism 
> for a "function" based trace systems.
>
> Are you intending to run the "user extension" and "function" tracing at 
> the same time ?
Yes.
>> Jennifer is plowing ahead logging variable length records and eliminating
>> fields in the capture task control but we don't see how to get rid of
>> all of it.
> I feel we may need some data in the TCB yet I do not think we need all 
> the fields in current code.
>
> In the first pass of "function" tracing I think a single bit per task 
> for any function called in the task's context to raise the trigger. This 
> means a global table of bits for all functions to control the function 
> specific trace and trigger control and then a bit per task for any 
> function triggered or traced (once triggered) to allow filtering by 
> task. We might get away with a single 32bit value (actually a 
> sizeof(void*)) in the TCB.
>
> If the need for more memory grows the TCB value could be changed to a 
> pointer that reference a buffer taken from a private capture engine pool 
> of buffers created when it starts based on a user specified size. In 
> this case lack of buffers would simply log the error and user would need 
> to adjust the value.
OK. Moving the filter to the TCB seems to address this need.

We can get the information in the TCB first and then worry about
tightening the representation.
> Chris

-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel.sherrill at OARcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available                (256) 722-9985