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

[Sebastian Huber]

On 2014-04-09 02:49, Chris Johns wrote:
> 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 ?" ?

It seems that I am not long enough in the project, since this question didn't 
occur to me.  I never configured RTEMS by other means than confdefs.h.  All 
tests and examples use it.  We should make it clear in

http://rtems.org/onlinedocs/doc-current/share/rtems/html/c_user/Configuring-a-System.html#Configuring-a-System

that condefs.h is THE way to configure RTEMS.

-- 
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.