[PATCH] Add a user argument to 'rtems_iterate_over_all_threads'.

Sebastian Huber sebastian.huber at embedded-brains.de
Wed Jul 13 08:36:02 UTC 2016

I think it is very bad that <rtems.h> exposes Thread_Control via 
rtems_tcb directly. It is also bad that the user extensions directly use 
tcb->extensions[index] to get their data. It would be better to have an 
accessor function and hide the data structure. Maybe we should just add 
a forward declaration to <rtems.h>

typedef struct _Thread_Control rtems_tcb;

and provide a global accessor for the extensions data, e.g.

void *rtems_extensions_get_data(rtems_id extension_id, rtems_tcb *tcb);

Then remove the Thread_Control visibility from <rtems.h>. User that 
really need the internals must include <rtems/score/thread.h>.

On 13/07/16 10:27, Chris Johns wrote:
> On 13/07/2016 4:16 PM, Sebastian Huber wrote:
>> Since this rtems_iterate_over_all_threads() is documented in the user
>> manual should we keep it as is and just add a new variant?
> I would prefer we fix the current API because what you can do with it as
> it stands is limited.
> Locking the object allocator lock changes things and requires people
> review their usage. Maybe a change is a good thing.
>> There is also a related ticket:
>> https://devel.rtems.org/ticket/2423
> Oh yes it is, I did not notice this. Hmmm.
> This is a difficult interface to place in the RTEMS API because it
> crosses a boundaries with the SCORE. The argument for the visitor
> function is an SCORE type and the function is declared in the SCORE's
> thread.h header which is not good to see slip into the code. I question
> it being documented here and this way.
> A user is exposed to any changes in the SCORE implementation of the
> Thread_Control so it is difficult to make this API always stable.
> Chris

Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax     : +49 89 189 47 41-09
E-Mail  : sebastian.huber at embedded-brains.de
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.

More information about the devel mailing list