[PATCH 2/3] score: Simplify thread control initialization

[Chris Johns]

On 9/04/2014 12:15 am, Sebastian Huber wrote:
> The thread control block contains fields that point to application
> configuration dependent memory areas, like the scheduler information,
> the API control blocks, the user extension context table, the RTEMS
> notepads and the Newlib re-entrancy support.  Account for these areas in
> the configuration and avoid extra workspace allocations for these areas.

This is a nice goal to aim for. I do have some questions related how we 
see confdefs.h in RTEMS these days.

> This helps also to avoid heap fragementation and reduces the per thread
> memory due to a reduced heap allocation overhead.

Nice.

> diff --git a/cpukit/sapi/include/confdefs.h b/cpukit/sapi/include/confdefs.h
> index cac87d3..2a37474 100644
> --- a/cpukit/sapi/include/confdefs.h
> +++ b/cpukit/sapi/include/confdefs.h


> +
> +  const size_t _Thread_Control_size = sizeof( Configuration_Thread_control );
> +
> +  const Thread_Control_add_on _Thread_Control_add_ons[] = {
> +    {
> +      offsetof( Configuration_Thread_control, Control.scheduler_info ),
> +      offsetof( Configuration_Thread_control, Scheduler )
> +    }, {
> +      offsetof(
> +        Configuration_Thread_control,
> +        Control.API_Extensions[ THREAD_API_RTEMS ]
> +      ),
> +      offsetof( Configuration_Thread_control, API_RTEMS )
> +    }, {
> +      offsetof(
> +        Configuration_Thread_control,
> +        Control.libc_reent
> +      ),
> +      offsetof( Configuration_Thread_control, Newlib )
> +    }
> +    #ifdef RTEMS_POSIX_API
> +      , {
> +        offsetof(
> +          Configuration_Thread_control,
> +          Control.API_Extensions[ THREAD_API_POSIX ]
> +        ),
> +        offsetof( Configuration_Thread_control, API_POSIX )
> +      }
> +    #endif
> +  };
> +
> +  const size_t _Thread_Control_add_on_count =
> +    RTEMS_ARRAY_SIZE( _Thread_Control_add_ons );
> +

  [snip]

> diff --git a/cpukit/score/include/rtems/score/thread.h b/cpukit/score/include/rtems/score/thread.h
> index aae9a72..61e6bc0 100644
> --- a/cpukit/score/include/rtems/score/thread.h
> +++ b/cpukit/score/include/rtems/score/thread.h
> @@ -582,8 +582,6 @@ struct Thread_Control_struct {
>     struct _reent                        *libc_reent;
>     /** This array contains the API extension area pointers. */
>     void                                 *API_Extensions[ THREAD_API_LAST + 1 ];
> -  /** This field points to the user extension pointers. */
> -  void                                **extensions;
>
>   #if !defined(RTEMS_SMP)
>     /** This field points to the set of per task variables. */
> @@ -600,6 +598,13 @@ struct Thread_Control_struct {
>     Chain_Control           Key_Chain;
>
>     Thread_Life_control                   Life;
> +
> +  /**
> +   * @brief Variable length array of user extension pointers.
> +   *
> +   * The length is defined by the application via <rtems/confdefs.h>.
> +   */
> +  void                                 *extensions[ 0 ];
>   };
>
>   #if (CPU_PROVIDES_IDLE_THREAD_BODY == FALSE)
> @@ -654,6 +659,57 @@ RTEMS_INLINE_ROUTINE Thread_Control *_Thread_Get_executing( void )
>     return executing;
>   }
>
> +/**
> + * @brief Thread control add-on.
> + */
> +typedef struct {
> +  /**
> +   * @brief Offset of the pointer field in Thread_Control referencing an
> +   * application configuration dependent memory area in the thread control
> +   * block.
> +   */
> +  size_t destination_offset;
> +
> +  /**
> +   * @brief Offset relative to the thread control block begin to an application
> +   * configuration dependent memory area.
> +   */
> +  size_t source_offset;
> +} Thread_Control_add_on;
> +
> +/**
> + * @brief Thread control add-ons.
> + *
> + * The thread control block contains fields that point to application
> + * configuration dependent memory areas, like the scheduler information, the
> + * API control blocks, the user extension context table, the RTEMS notepads and
> + * the Newlib re-entrancy support.  Account for these areas in the
> + * configuration and avoid extra workspace allocations for these areas.
> + *
> + * This array is provided via <rtems/confdefs.h>.
> + *
> + * @see _Thread_Control_add_on_count and _Thread_Control_size.
> + */
> +extern const Thread_Control_add_on _Thread_Control_add_ons[];
> +
> +/**
> + * @brief Thread control add-on count.
> + *
> + * Count of entries in _Thread_Control_add_ons.
> + *
> + * This value is provided via <rtems/confdefs.h>.
> + */
> +extern const size_t _Thread_Control_add_on_count;
> +
> +/**
> + * @brief Size of the thread control block of a particular application.
> + *
> + * This value is provided via <rtems/confdefs.h>.
> + *
> + * @see _Thread_Control_add_ons.
> + */
> +extern const size_t _Thread_Control_size;
> +

This approach further changes the "standard" way to configuring RTEMS. I 
suspect it may have already changed and this change moves the position a 
little further. I think we need to acknowledge this and sort out what it 
means, ie documentation.

The confdefs.h file started as a way to create the configuration tables 
and to help users. A user was always able to create the underlying 
tables and manage the process themselves. Changes like this and a number 
of others in confdefs.h are not documented in user manuals. Does this 
means we are starting to say "When configuring RTEMS use confdefs.h ?" ?

Chris