Tracing task id.

[Joel Sherrill]

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.

--joel

If you cut the node number down to
> Gedare
>
> On Wed, Mar 25, 2015 at 10:52 PM, Chris Johns<chrisj at rtems.org>  wrote:
>> Hi,
>>
>> Is there are bit in the Id that could be reserved and used to record the
>> interrupt nesting state when tracing ?
>>
>> This saves having to find a bit somewhere else in record to capture this
>> piece of information. I am thinking about testing the irq nesting level
>> and if set recording this.
>>
>> Chris
>> _______________________________________________
>> devel mailing list
>> devel at rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel
> _______________________________________________
> devel mailing list
> devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel


-- 
-- Joel Sherrill
Ask me about RTEMS: a free RTOS
Support and Training Available