On 13/07/2016 19:52, Chris Johns wrote:
I will take this away and come back with something. I need a suitable
interface for something I am working on.
My need for this change does not exist any more so I will not be doing
any further work on it.
Chris
On 13/07/2016 6:36 PM, Sebastian Huber wrote:
> I think it is very bad that 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 structur
On Wed, Jul 13, 2016 at 3:27 AM, 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 c
I think it is very bad that 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
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 allo
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?
There is also a related ticket:
https://devel.rtems.org/ticket/2423
--
Sebastian Huber, embedded brains GmbH
Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phon
