[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