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.hu...@embedded-brains.de
PGP : Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
