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