Tracing task id.

[Chris Johns]

On 27/03/2015 12:47 am, Joel Sherrill wrote:
> On 03/26/2015 08:41 AM, Gedare Bloom wrote:
>> There are unused fields in the (32-bit) Objects_Id, but none are
>> "reserved". Currently only 2-bits of the API are used, although 4 bits
>> are available. Also, if you're not using RTEMS_MULTIPROCESSING, I
>> guess none of the node bits are used.
>>
> Look at _Objects_Get. The way an ID is converted to a pointer
> assumes the ID is within a certain numeric range. The node
> number could be repurposed but we would have to be careful
> not to break this and would also have to be careful for
> calls like rtems_task_self() and pthread_self().
> 
> You want this to work in all configurations. I would propose
> considering cutting the node number down to a smaller
> number of bits and masking those out in _Thread_Get()
> and the methods that return the current ID. We would
> really have to be careful about fetching a thread ID though
> to ensure that the variable field doesn't get in the way
> of the constant use.
> 

This is just for the trace data and not for use in the target. It might
not be that useful after all. In the latest trace buffer generator I
pushed I need record the current/real priority and task state (not sure
about this one) which is a bunch more bits I need anyway so I can use
some available ones there.

Chris