[PATCH 2/4] score: Documentation
---
cpukit/score/include/rtems/score/threadq.h | 31 --
1 file changed, 29 insertions(+), 2 deletions(-)
diff --git a/cpukit/score/include/rtems/score/threadq.h
b/cpukit/score/include/rtems/score/threadq.h
index 8f2b138..2b58310 100644
--- a/cpukit/score/include/rtems/score/threadq.h
+++ b/cpukit/score/include/rtems/score/threadq.h
@@ -44,6 +44,13 @@ typedef struct _Thread_Control Thread_Control;
/**
* @brief Thread queue heads.
*
+ * Each thread is equipped with spare thread queue heads in case it not
+ * enqueued on a thread queue. The first thread enqueued on a thread queue
+ * will give its spare thread queue heads to this thread queue. The threads
+ * arriving at the queue will add their thread queue heads to the free chain of
+ * the queue heads provided by the first thread enqueued. Once a thread is
+ * dequeued it use the free chain to get new spare thread queue heads.
+ *
* Uses a leading underscore in the structure name to allow forward
* declarations in standard header files provided by Newlib and GCC.
*/
@@ -52,18 +59,38 @@ typedef struct _Thread_queue_Heads {
* set of tasks which varies based upon the discipline.
*/
union {
-/** This is the FIFO discipline list. */
+/**
+ * @brief This is the FIFO discipline list.
+ */
Chain_Control Fifo;
-/** This is the set of threads for priority discipline waiting. */
+
+/**
+ * @brief This is the set of threads for priority discipline waiting.
+ */
RBTree_Control Priority;
} Heads;
+ /**
+ * @brief A chain with free thread queue heads providing the spare thread
+ * queue heads for a thread once it is dequeued.
+ */
Chain_Control Free_chain;
+ /**
+ * @brief A chain node to add these thread queue heads to the free chain of
+ * the thread queue heads dedicated to the thread queue of an object.
+ */
Chain_Node Free_node;
} Thread_queue_Heads;
typedef struct {
+ /**
+ * @brief The thread queue heads.
+ *
+ * This pointer is NULL, if and only if no threads are enqueued. The first
+ * thread to enqueue will give its spare thread queue heads to this thread
+ * queue.
+ */
Thread_queue_Heads *heads;
/**
--
1.8.4.5
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCH 4/4] score: Implement priority boosting
---
cpukit/score/include/rtems/score/threadimpl.h | 31 +
cpukit/score/include/rtems/score/threadqimpl.h | 25 +++
cpukit/score/src/coremutexseize.c | 2 +-
cpukit/score/src/coremutexsurrender.c | 1 +
cpukit/score/src/mutex.c | 15 ---
cpukit/score/src/threadchangepriority.c| 34 ++
cpukit/score/src/threadqops.c | 22 ++
doc/user/sem.t | 5 +++
doc/user/smp.t | 6 ++-
testsuites/smptests/smpmutex01/init.c | 61 +++---
10 files changed, 189 insertions(+), 13 deletions(-)
diff --git a/cpukit/score/include/rtems/score/threadimpl.h
b/cpukit/score/include/rtems/score/threadimpl.h
index 4656881..1092b65 100644
--- a/cpukit/score/include/rtems/score/threadimpl.h
+++ b/cpukit/score/include/rtems/score/threadimpl.h
@@ -437,6 +437,37 @@ void _Thread_Raise_priority(
);
/**
+ * @brief Inherit the priority of a thread.
+ *
+ * It changes the current priority of the inheritor thread to the current
priority
+ * of the ancestor thread if it is higher than the current priority of the
inheritor
+ * thread. In this case the inheritor thread is appended to its new priority
group
+ * in its scheduler instance.
+ *
+ * On SMP configurations, the priority is changed to PRIORITY_PSEUDO_ISR in
+ * case the own schedulers of the inheritor and ancestor thread differ
(priority
+ * boosting).
+ *
+ * @param[in] inheritor The thread to inherit the priority.
+ * @param[in] ancestor The thread to bequeath its priority to the inheritor
+ * thread.
+ */
+#if defined(RTEMS_SMP)
+void _Thread_Inherit_priority(
+ Thread_Control *inheritor,
+ Thread_Control *ancestor
+);
+#else
+RTEMS_INLINE_ROUTINE void _Thread_Inherit_priority(
+ Thread_Control *inheritor,
+ Thread_Control *ancestor
+)
+{
+ _Thread_Raise_priority( inheritor, ancestor->current_priority );
+}
+#endif
+
+/**
* @brief Sets the current to the real priority of a thread.
*
* Sets the priority restore hint to false.
diff --git a/cpukit/score/include/rtems/score/threadqimpl.h
b/cpukit/score/include/rtems/score/threadqimpl.h
index bf01eb7..510f886 100644
--- a/cpukit/score/include/rtems/score/threadqimpl.h
+++ b/cpukit/score/include/rtems/score/threadqimpl.h
@@ -522,6 +522,31 @@ RTEMS_INLINE_ROUTINE void _Thread_queue_Destroy(
}
/**
+ * @brief Boosts the priority of the thread if threads of another scheduler
+ * instance are enqueued on the thread queue.
+ *
+ * The thread queue must use the priority waiting discipline.
+ *
+ * @param[in] queue The actual thread queue.
+ * @param[in] the_thread The thread to boost the priority if necessary.
+ */
+#if defined(RTEMS_SMP)
+void _Thread_queue_Boost_priority(
+ Thread_queue_Queue *queue,
+ Thread_Control *the_thread
+);
+#else
+RTEMS_INLINE_ROUTINE void _Thread_queue_Boost_priority(
+ Thread_queue_Queue *queue,
+ Thread_Control *the_thread
+)
+{
+ (void) queue;
+ (void) the_thread;
+}
+#endif
+
+/**
* @brief Compare two thread's priority for RBTree Insertion.
*
* @param[in] left points to the left thread's RBnode
diff --git a/cpukit/score/src/coremutexseize.c
b/cpukit/score/src/coremutexseize.c
index ddc5d6b..8059659 100644
--- a/cpukit/score/src/coremutexseize.c
+++ b/cpukit/score/src/coremutexseize.c
@@ -75,7 +75,7 @@ void _CORE_mutex_Seize_interrupt_blocking(
_Thread_queue_Release( &the_mutex->Wait_queue, lock_context );
#endif
-_Thread_Raise_priority( holder, executing->current_priority );
+_Thread_Inherit_priority( holder, executing );
#if !defined(RTEMS_SMP)
_Thread_queue_Acquire( &the_mutex->Wait_queue, lock_context );
diff --git a/cpukit/score/src/coremutexsurrender.c
b/cpukit/score/src/coremutexsurrender.c
index d3f965d..7d9c57f 100644
--- a/cpukit/score/src/coremutexsurrender.c
+++ b/cpukit/score/src/coremutexsurrender.c
@@ -209,6 +209,7 @@ CORE_mutex_Status _CORE_mutex_Surrender(
case CORE_MUTEX_DISCIPLINES_PRIORITY_INHERIT:
_CORE_mutex_Push_priority( the_mutex, the_thread );
the_thread->resource_count++;
+ _Thread_queue_Boost_priority( &the_mutex->Wait_queue.Queue,
the_thread );
break;
case CORE_MUTEX_DISCIPLINES_PRIORITY_CEILING:
_CORE_mutex_Push_priority( the_mutex, the_thread );
diff --git a/cpukit/score/src/mutex.c b/cpukit/score/src/mutex.c
index ae637dd..f03bab7 100644
--- a/cpukit/score/src/mutex.c
+++ b/cpukit/score/src/mutex.c
@@ -112,9 +112,7 @@ static void _Mutex_Acquire_slow(
ISR_lock_Context *lock_context
)
{
- /* Priority inheritance */
- _Thread_Raise_priority( owner, executing->current_priority );
-
+ _Thread_Inherit_priority( owner, executing );
_Thread_queue_Enqueue_critical(
&mutex->Queue.Queue,
MUTEX_TQ_OPERATIONS,
@@ -136,15 +134,22 @@ static void _Mutex_Release_slow(
{
if (heads != NULL) {
const Thread_queue_Operations *op
[PATCH 1/4] smp: Documentation
---
doc/user/smp.t | 38 ++
1 file changed, 38 insertions(+)
diff --git a/doc/user/smp.t b/doc/user/smp.t
index 1b4849a..ba700e0 100644
--- a/doc/user/smp.t
+++ b/doc/user/smp.t
@@ -147,6 +147,44 @@ another processor. So if we enable interrupts during this
transition we have
to provide an alternative task independent stack for this time frame. This
issue needs further investigation.
+@subsection Clustered/Partitioned Scheduling
+
+We have clustered scheduling in case the set of processors of a system is
+partitioned into non-empty pairwise-disjoint subsets. These subsets are called
+clusters. Clusters with a cardinality of one are partitions. Each cluster is
+owned by exactly one scheduler instance.
+
+Clustered/partitioned scheduling helps to control the worst-case latencies in
+the system, see @cite{Brandenburg, Bj??rn B.: Scheduling and Locking in
+Multiprocessor Real-Time Operating Systems. PhD thesis, 2011.
+@uref{http://www.cs.unc.edu/~bbb/diss/brandenburg-diss.pdf}}. The goal is to
+reduce the amount of shared state in the system and thus prevention of lock
+contention. Modern multi-processor systems tend to have several layers of data
+and instruction caches. With clustered/partitioned scheduling it is possible to
+honour the cache topology of a system and thus avoid expensive cache
+synchronization traffic. It is easy to implement. The problem is to provide
+synchronization primitives for inter-partition synchronization. In RTEMS there
+are currently three means available
+
+@itemize @bullet
+@item events,
+@item message queues, and
+@item semaphores using the @ref{Semaphore Manager Multiprocessor Resource
+Sharing Protocol} (MrsP).
+@end itemize
+
+The clustered/partitioned scheduling approach enables separation of functions
+with real-time requirements and functions that profit from fairness and high
+throughput provided the scheduler instances are fully decoupled and adequate
+intra-partition synchronization primitives are used. This is work in progress.
+
+For the configuration of clustered/partitioned schedulers see @ref{Configuring
+a System Configuring Clustered/Partitioned Schedulers}.
+
+To set the scheduler of a task see @ref{Symmetric Multiprocessing Services
+SCHEDULER_IDENT - Get ID of a scheduler} and @ref{Symmetric Multiprocessing
+Services TASK_SET_SCHEDULER - Set scheduler of a task}.
+
@subsection Scheduler Helping Protocol
The scheduler provides a helping protocol to support locking protocols like
--
1.8.4.5
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCH 3/4] score: Implement SMP specific priority queue
---
cpukit/sapi/include/confdefs.h | 7 +-
cpukit/score/include/rtems/score/threadq.h | 44 +++-
cpukit/score/include/rtems/score/threadqimpl.h | 16 ++
cpukit/score/src/thread.c | 3 +-
cpukit/score/src/threadinitialize.c| 4 +-
cpukit/score/src/threadqops.c | 70 +-
doc/user/smp.t | 54
testsuites/smptests/Makefile.am| 1 +
testsuites/smptests/configure.ac | 1 +
testsuites/smptests/smpmutex01/Makefile.am | 19 ++
testsuites/smptests/smpmutex01/init.c | 326 +
testsuites/smptests/smpmutex01/smpmutex01.doc | 14 ++
testsuites/smptests/smpmutex01/smpmutex01.scn | 2 +
13 files changed, 545 insertions(+), 16 deletions(-)
create mode 100644 testsuites/smptests/smpmutex01/Makefile.am
create mode 100644 testsuites/smptests/smpmutex01/init.c
create mode 100644 testsuites/smptests/smpmutex01/smpmutex01.doc
create mode 100644 testsuites/smptests/smpmutex01/smpmutex01.scn
diff --git a/cpukit/sapi/include/confdefs.h b/cpukit/sapi/include/confdefs.h
index 4b438ff..66c8c7e 100644
--- a/cpukit/sapi/include/confdefs.h
+++ b/cpukit/sapi/include/confdefs.h
@@ -1008,9 +1008,10 @@ const rtems_libio_helper rtems_fs_init_helper =
CONFIGURE_SCHEDULER_CONTROLS
};
+ #define CONFIGURE_SCHEDULER_COUNT RTEMS_ARRAY_SIZE( _Scheduler_Table )
+
#if defined(RTEMS_SMP)
-const size_t _Scheduler_Count =
- RTEMS_ARRAY_SIZE( _Scheduler_Table );
+const size_t _Scheduler_Count = CONFIGURE_SCHEDULER_COUNT;
const Scheduler_Assignment _Scheduler_Assignments[] = {
#if defined(CONFIGURE_SMP_SCHEDULER_ASSIGNMENTS)
@@ -2970,7 +2971,7 @@ const rtems_libio_helper rtems_fs_init_helper =
( \
_Configure_Object_RAM(_tasks, sizeof(Configuration_Thread_control)) \
+ _Configure_From_workspace(_Configure_Max_Objects(_tasks) \
-* sizeof(Thread_queue_Heads)) \
+* THREAD_QUEUE_HEADS_SIZE(CONFIGURE_SCHEDULER_COUNT)) \
+ _Configure_Max_Objects(_number_FP_tasks) \
* _Configure_From_workspace(CONTEXT_FP_SIZE) \
)
diff --git a/cpukit/score/include/rtems/score/threadq.h
b/cpukit/score/include/rtems/score/threadq.h
index 2b58310..a877c4e 100644
--- a/cpukit/score/include/rtems/score/threadq.h
+++ b/cpukit/score/include/rtems/score/threadq.h
@@ -42,6 +42,26 @@ extern "C" {
typedef struct _Thread_Control Thread_Control;
/**
+ * @brief Thread priority queue.
+ */
+typedef struct {
+#if defined(RTEMS_SMP)
+ /**
+ * @brief Node to enqueue this queue in the FIFO chain of the corresponding
+ * heads structure.
+ *
+ * @see Thread_queue_Heads::Heads::Fifo.
+ */
+ Chain_Node Node;
+#endif
+
+ /**
+ * @brief The actual thread priority queue.
+ */
+ RBTree_Control Queue;
+} Thread_queue_Priority_queue;
+
+/**
* @brief Thread queue heads.
*
* Each thread is equipped with spare thread queue heads in case it not
@@ -61,13 +81,19 @@ typedef struct _Thread_queue_Heads {
union {
/**
* @brief This is the FIFO discipline list.
+ *
+ * On SMP configurations this FIFO is used to enqueue the per scheduler
+ * instance priority queues of this structure. This ensures FIFO fairness
+ * among the highest priority thread of each scheduler instance.
*/
Chain_Control Fifo;
+#if !defined(RTEMS_SMP)
/**
* @brief This is the set of threads for priority discipline waiting.
*/
-RBTree_Control Priority;
+Thread_queue_Priority_queue Priority;
+#endif
} Heads;
/**
@@ -81,8 +107,24 @@ typedef struct _Thread_queue_Heads {
* the thread queue heads dedicated to the thread queue of an object.
*/
Chain_Node Free_node;
+
+#if defined(RTEMS_SMP)
+ /**
+ * @brief One priority queue per scheduler instance.
+ */
+ Thread_queue_Priority_queue Priority[ RTEMS_ZERO_LENGTH_ARRAY ];
+#endif
} Thread_queue_Heads;
+#if defined(RTEMS_SMP)
+ #define THREAD_QUEUE_HEADS_SIZE( scheduler_count ) \
+( sizeof( Thread_queue_Heads ) \
+ + ( scheduler_count ) * sizeof( Thread_queue_Priority_queue ) )
+#else
+ #define THREAD_QUEUE_HEADS_SIZE( scheduler_count ) \
+sizeof( Thread_queue_Heads )
+#endif
+
typedef struct {
/**
* @brief The thread queue heads.
diff --git a/cpukit/score/include/rtems/score/threadqimpl.h
b/cpukit/score/include/rtems/score/threadqimpl.h
index 3828f41..bf01eb7 100644
--- a/cpukit/score/include/rtems/score/threadqimpl.h
+++ b/cpukit/score/include/rtems/score/threadqimpl.h
@@ -22,6 +22,7 @@
#include
#include
#include
+#include
#include
#ifdef __cplusplus
@@ -51,6 +52,21 @@ typedef struct {
#endif
} Thread_queue_Syslock_queue;
+RTEMS_INLINE_ROUTINE void _Thread_queue_Heads_initialize(
+ Thread_queue_Heads *heads
+)
+{
+#if defined(RTEMS_SMP)
+ size_t i;
+
+ for ( i = 0; i < _Scheduler_Count; ++i ) {
+_RBTree_Initialize_empty( &heads->Priority[ i ].Queue )
[PATCH] smp: Documentation
---
doc/user/smp.t | 66 ++
1 file changed, 66 insertions(+)
diff --git a/doc/user/smp.t b/doc/user/smp.t
index 2ab9aaf..a06be8a 100644
--- a/doc/user/smp.t
+++ b/doc/user/smp.t
@@ -465,6 +465,72 @@ architecture please consult the @cite{RTEMS CPU
Architecture Supplement}.
The only remaining user of task variables in the RTEMS code base is the Ada
support. So basically Ada is not available on RTEMS SMP.
+@subsection OpenMP
+
+OpenMP support for RTEMS is available via the GCC provided libgomp. There is
+libgomp support for RTEMS in the POSIX configuration since GCC 4.9 (requires a
+Newlib snapshot after 2015-03-12). In GCC 6.1 or later (requires a Newlib
+snapshot after 2015-07-30 for provided self-contained
+synchronization objects) there is RTEMS support in a RTEMS specific
+configuration which offers a significantly better performance compared to the
+POSIX configuration (the term configuration refers here to the libgomp
+configuration and should not be confused with the POSIX API provided by RTEMS).
+In addition scheduler instance specific thread pools may be defined.
+
+The run-time configuration of libgomp is done via environment variables
+documented in the @uref{https://gcc.gnu.org/onlinedocs/libgomp/, libgomp
+manual}. The environment variables are evaluated in a constructor function
+which executes in the context of the first initialization task before the
+actual initialization task function is called (just like a global C++
+constructor). To set application specific values, a higher priority
+constructor function must be used to set up the environment variables.
+
+@example
+@group
+#include
+
+static void __attribute__((constructor(1000))) config_libgomp( void )
+@{
+ setenv( "OMP_DISPLAY_ENV", "VERBOSE", 1 );
+ setenv( "GOMP_SPINCOUNT", "3", 1 );
+ setenv( "GOMP_RTEMS_THREAD_POOLS", "1$2@@SCHD", 1 );
+@}
+@end group
+@end example
+
+The environment variable @env{GOMP_RTEMS_THREAD_POOLS} is RTEMS specific. It
+determines the scheduler instance specific thread pools. The format for
+@env{GOMP_RTEMS_THREAD_POOLS} is a list of optional
+@code{[$]@@} configurations
+separated by @code{:} where:
+
+@itemize @bullet
+@item @code{} is the thread pool count for this scheduler
+instance.
+@item @code{$} is an optional priority for the worker threads of a
+thread pool according to @code{pthread_setschedparam}. In case a priority
+value is omitted, then a worker thread will inherit the priority of the OpenMP
+master thread that created it. The priority of the worker thread is not
+changed after creation, even if a new OpenMP master thread using the worker has
+a different priority.
+@item @code{@@} is the scheduler instance name according to the
+RTEMS application configuration.
+@end itemize
+
+In case no thread pool configuration is specified for a scheduler instance,
+then each OpenMP master thread of this scheduler instance will use its own
+dynamically allocated thread pool. To limit the worker thread count of the
+thread pools, each OpenMP master thread must call @code{omp_set_num_threads}.
+
+Lets suppose we have three scheduler instances @code{IO}, @code{WRK0}, and
+@code{WRK1} with @env{GOMP_RTEMS_THREAD_POOLS} set to
+@code{"1@@WRK0:3$4@@WRK1"}. Then there are no thread pool restrictions for
+scheduler instance @code{IO}. In the scheduler instance @code{WRK0} there is
+one thread pool available. Since no priority is specified for this scheduler
+instance, the worker thread inherits the priority of the OpenMP master thread
+that created it. In the scheduler instance @code{WRK1} there are three thread
+pools available and their worker threads run at priority four.
+
@subsection Thread Dispatch Details
This section gives background information to developers interested in the
--
1.8.4.5
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] [RTEMS] Update RTEMS thread model
Hi Sebastian! Thanks for your answer. There are a couple of things I
still don't get :)
On Thu, Sep 3, 2015 at 2:48 AM, Sebastian Huber
wrote:
> I updated the rtems-testing repository.
>
> 1. You have to adjust the VERSIONS file.
Is this file meant to help the scripts download the tool sources
automatically (like RSB does), or does it just point to local
directories where I'm supposed to place them? If it downloads them
automatically, should I replace 'cvs' by 'git' for e.g. gdb?
> 2. You need the latest Git versions of Newlib, GCC and RTEMS.
So I should manually build a cross-gcc from the gcc trunk? I think
that's past 5.2, will RTEMS build ok with that?
Also, should I apply the patch you posted here:
https://gcc.gnu.org/ml/gcc-patches/2015-09/msg00019.html
?
> 3. Use
>
> ./do_one -1 -r -g -v -M arm realview_pbx_a9_qemu
>
> to run the GCC tests. Make sure the test runner "realview_pbx_a9_qemu"
> works.
How can I test that? Should I build the realview_pbx_a9 BSP and run a
sample (e.g. ticker) on the latest Qemu?
> 4. Use something similar
>
> cd gcc/b-arm-gcc/arm-rtems4.11/libstdc++-v3/testsuite
> make check 'RUNTESTFLAGS= SIM=realview_pbx_a9_qemu
> RTEMS_MAKEFILE_PATH=/scratch/git-rtems-testing/gcc/install-git/arm-rtems4.11/realview_pbx_a9_qemu
> RTEMS_CONFIG_OBJ=/scratch/git-rtems-testing/gcc/b-arm-gcc/rtems_gcc_main.o
> --target_board=rtems-arm-realview_pbx_a9_qemu{-march=armv7-a/-mthumb/-mfpu=neon/-mfloat-abi=hard}'
>
> to run the libstdc++ tests.
Where does the /git-rtems-testing/gcc/install-git directory? I didn't
see an 'install-git' dir inside rtems-testing/gcc. Is it created after
doing make install on rtems-testing?
Thanks a lot.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH 1/4] smp: Documentation
On Thu, Sep 3, 2015 at 8:01 AM, Sebastian Huber
wrote:
> ---
> doc/user/smp.t | 38 ++
> 1 file changed, 38 insertions(+)
>
> diff --git a/doc/user/smp.t b/doc/user/smp.t
> index 1b4849a..ba700e0 100644
> --- a/doc/user/smp.t
> +++ b/doc/user/smp.t
> @@ -147,6 +147,44 @@ another processor. So if we enable interrupts during
> this transition we have
> to provide an alternative task independent stack for this time frame. This
> issue needs further investigation.
>
> +@subsection Clustered/Partitioned Scheduling
> +
> +We have clustered scheduling in case the set of processors of a system is
> +partitioned into non-empty pairwise-disjoint subsets. These subsets are
> called
> +clusters. Clusters with a cardinality of one are partitions. Each cluster
> is
> +owned by exactly one scheduler instance.
> +
> +Clustered/partitioned scheduling helps to control the worst-case latencies in
> +the system, see @cite{Brandenburg, Björn B.: Scheduling and Locking in
> +Multiprocessor Real-Time Operating Systems. PhD thesis, 2011.
> +@uref{http://www.cs.unc.edu/~bbb/diss/brandenburg-diss.pdf}}. The goal is to
> +reduce the amount of shared state in the system and thus prevention of lock
> +contention. Modern multi-processor systems tend to have several layers of
> data
> +and instruction caches. With clustered/partitioned scheduling it is possible
> to
> +honour the cache topology of a system and thus avoid expensive cache
> +synchronization traffic. It is easy to implement. The problem is to provide
> +synchronization primitives for inter-partition synchronization. In RTEMS
> there
> +are currently three means available
> +
> +@itemize @bullet
> +@item events,
> +@item message queues, and
> +@item semaphores using the @ref{Semaphore Manager Multiprocessor Resource
> +Sharing Protocol} (MrsP).
> +@end itemize
> +
> +The clustered/partitioned scheduling approach enables separation of functions
> +with real-time requirements and functions that profit from fairness and high
> +throughput provided the scheduler instances are fully decoupled and adequate
> +intra-partition synchronization primitives are used. This is work in
> progress.
inter-partition? inter-partition doesn't make sense. Also, to be
general, it should really be inter-cluster, which goes for the above
use of "inter-partition" as well. Because of the use of partition in
Partitioned Scheduling, we have to be careful about the use of
partition in other places related to SMP scheduling, unfortunately.
> +
> +For the configuration of clustered/partitioned schedulers see
> @ref{Configuring
> +a System Configuring Clustered/Partitioned Schedulers}.
> +
> +To set the scheduler of a task see @ref{Symmetric Multiprocessing Services
> +SCHEDULER_IDENT - Get ID of a scheduler} and @ref{Symmetric Multiprocessing
> +Services TASK_SET_SCHEDULER - Set scheduler of a task}.
> +
> @subsection Scheduler Helping Protocol
>
> The scheduler provides a helping protocol to support locking protocols like
> --
> 1.8.4.5
>
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] smp: Documentation
On Thu, Sep 3, 2015 at 8:46 AM, Sebastian Huber
wrote:
> ---
> doc/user/smp.t | 66
> ++
> 1 file changed, 66 insertions(+)
>
> diff --git a/doc/user/smp.t b/doc/user/smp.t
> index 2ab9aaf..a06be8a 100644
> --- a/doc/user/smp.t
> +++ b/doc/user/smp.t
> @@ -465,6 +465,72 @@ architecture please consult the @cite{RTEMS CPU
> Architecture Supplement}.
> The only remaining user of task variables in the RTEMS code base is the Ada
> support. So basically Ada is not available on RTEMS SMP.
>
> +@subsection OpenMP
> +
> +OpenMP support for RTEMS is available via the GCC provided libgomp. There is
> +libgomp support for RTEMS in the POSIX configuration since GCC 4.9 (requires
> a
> +Newlib snapshot after 2015-03-12). In GCC 6.1 or later (requires a Newlib
> +snapshot after 2015-07-30 for provided self-contained
Do these versions relate to any release versions of RTEMS, e.g. did
this stuff make it into the toolchains for 4.11? Translating between
gcc/newlib versions and RTEMS versions is a bit of work for casual
user to know if this support will be available or not for them.
> +synchronization objects) there is RTEMS support in a RTEMS specific
hyphenate: "RTEMS-specific" here and below.
> +configuration which offers a significantly better performance compared to the
"libgomp configuration"
> +POSIX configuration (the term configuration refers here to the libgomp
> +configuration and should not be confused with the POSIX API provided by
> RTEMS).
> +In addition scheduler instance specific thread pools may be defined.
Last sentence doesn't say why that matters. Perhaps just say something
about discussing this further below.
> +
> +The run-time configuration of libgomp is done via environment variables
> +documented in the @uref{https://gcc.gnu.org/onlinedocs/libgomp/, libgomp
> +manual}. The environment variables are evaluated in a constructor function
> +which executes in the context of the first initialization task before the
> +actual initialization task function is called (just like a global C++
> +constructor). To set application specific values, a higher priority
hyphenate: "application-specific"
> +constructor function must be used to set up the environment variables.
> +
> +@example
> +@group
> +#include
> +
> +static void __attribute__((constructor(1000))) config_libgomp( void )
> +@{
> + setenv( "OMP_DISPLAY_ENV", "VERBOSE", 1 );
> + setenv( "GOMP_SPINCOUNT", "3", 1 );
> + setenv( "GOMP_RTEMS_THREAD_POOLS", "1$2@@SCHD", 1 );
> +@}
> +@end group
> +@end example
> +
The following discussion may warrant it's own subsection on Thread Pools.
> +The environment variable @env{GOMP_RTEMS_THREAD_POOLS} is RTEMS specific. It
> +determines the scheduler instance specific thread pools. The format for
hyphenate: "instance-specific"
> +@env{GOMP_RTEMS_THREAD_POOLS} is a list of optional
> +@code{[$]@@} configurations
> +separated by @code{:} where:
> +
> +@itemize @bullet
> +@item @code{} is the thread pool count for this scheduler
> +instance.
> +@item @code{$} is an optional priority for the worker threads of a
> +thread pool according to @code{pthread_setschedparam}. In case a priority
> +value is omitted, then a worker thread will inherit the priority of the
> OpenMP
> +master thread that created it. The priority of the worker thread is not
> +changed after creation, even if a new OpenMP master thread using the worker
> has
This statement "priority of the worker thread is not changed after
creation" probably is not accurate, in case of PIP/PCP or API calls to
change priority. It might be better to state that the priority is not
changed despite a change in the master thread?
> +a different priority.
> +@item @code{@@} is the scheduler instance name according to
> the
> +RTEMS application configuration.
> +@end itemize
> +
> +In case no thread pool configuration is specified for a scheduler instance,
> +then each OpenMP master thread of this scheduler instance will use its own
> +dynamically allocated thread pool. To limit the worker thread count of the
> +thread pools, each OpenMP master thread must call @code{omp_set_num_threads}.
> +
> +Lets suppose we have three scheduler instances @code{IO}, @code{WRK0}, and
> +@code{WRK1} with @env{GOMP_RTEMS_THREAD_POOLS} set to
> +@code{"1@@WRK0:3$4@@WRK1"}. Then there are no thread pool restrictions for
> +scheduler instance @code{IO}. In the scheduler instance @code{WRK0} there is
> +one thread pool available. Since no priority is specified for this scheduler
> +instance, the worker thread inherits the priority of the OpenMP master thread
> +that created it. In the scheduler instance @code{WRK1} there are three
> thread
> +pools available and their worker threads run at priority four.
> +
> @subsection Thread Dispatch Details
>
> This section gives background information to developers interested in the
> --
> 1.8.4.5
>
> ___
> devel m
Re: [PATCH 2/4] score: Documentation
On Thu, Sep 3, 2015 at 8:01 AM, Sebastian Huber
wrote:
> ---
> cpukit/score/include/rtems/score/threadq.h | 31
> --
> 1 file changed, 29 insertions(+), 2 deletions(-)
>
> diff --git a/cpukit/score/include/rtems/score/threadq.h
> b/cpukit/score/include/rtems/score/threadq.h
> index 8f2b138..2b58310 100644
> --- a/cpukit/score/include/rtems/score/threadq.h
> +++ b/cpukit/score/include/rtems/score/threadq.h
> @@ -44,6 +44,13 @@ typedef struct _Thread_Control Thread_Control;
> /**
> * @brief Thread queue heads.
> *
> + * Each thread is equipped with spare thread queue heads in case it not
it not --> it is not
> + * enqueued on a thread queue. The first thread enqueued on a thread queue
> + * will give its spare thread queue heads to this thread queue. The threads
this --> that
> + * arriving at the queue will add their thread queue heads to the free chain
> of
> + * the queue heads provided by the first thread enqueued. Once a thread is
> + * dequeued it use the free chain to get new spare thread queue heads.
> + *
> * Uses a leading underscore in the structure name to allow forward
> * declarations in standard header files provided by Newlib and GCC.
> */
> @@ -52,18 +59,38 @@ typedef struct _Thread_queue_Heads {
> * set of tasks which varies based upon the discipline.
> */
>union {
> -/** This is the FIFO discipline list. */
> +/**
> + * @brief This is the FIFO discipline list.
> + */
> Chain_Control Fifo;
> -/** This is the set of threads for priority discipline waiting. */
> +
> +/**
> + * @brief This is the set of threads for priority discipline waiting.
> + */
> RBTree_Control Priority;
>} Heads;
>
> + /**
> + * @brief A chain with free thread queue heads providing the spare thread
> + * queue heads for a thread once it is dequeued.
> + */
>Chain_Control Free_chain;
>
> + /**
> + * @brief A chain node to add these thread queue heads to the free chain of
> + * the thread queue heads dedicated to the thread queue of an object.
> + */
>Chain_Node Free_node;
> } Thread_queue_Heads;
>
> typedef struct {
> + /**
> + * @brief The thread queue heads.
> + *
> + * This pointer is NULL, if and only if no threads are enqueued. The first
> + * thread to enqueue will give its spare thread queue heads to this thread
> + * queue.
> + */
>Thread_queue_Heads *heads;
>
>/**
> --
> 1.8.4.5
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH v2 5/5] cpukit/libnetworking/rtems/rtems_dhcp.c: Fix leak on realloc failure for dhcp_hostname.
Joel,
Review/Commit these if happy.
Gedare
On Wed, Sep 2, 2015 at 5:54 PM, Martin Galvan
wrote:
> Closes #2405.
> ---
> cpukit/libnetworking/rtems/rtems_dhcp.c | 18 +-
> 1 file changed, 13 insertions(+), 5 deletions(-)
>
> diff --git a/cpukit/libnetworking/rtems/rtems_dhcp.c
> b/cpukit/libnetworking/rtems/rtems_dhcp.c
> index c938ee0..87be238 100644
> --- a/cpukit/libnetworking/rtems/rtems_dhcp.c
> +++ b/cpukit/libnetworking/rtems/rtems_dhcp.c
> @@ -394,15 +394,23 @@ process_options (unsigned char *optbuf, int optbufSize)
>printf ("dhcpc: hostname >= %d bytes\n", MAXHOSTNAMELEN);
>len = MAXHOSTNAMELEN-1;
> }
> -if (sethostname (p, len) < 0)
> +if (sethostname (p, len) < 0) {
>printf ("dhcpc: can't set host name");
> +}
> if (dhcp_hostname != NULL)
> {
> - dhcp_hostname = realloc (dhcp_hostname, len);
> - strncpy (dhcp_hostname, p, len);
> -}
> -else
> + char *tmp = realloc (dhcp_hostname, len);
> + if (tmp != NULL) {
> +dhcp_hostname = tmp;
> +strncpy (dhcp_hostname, p, len);
> + } else { /* realloc failed */
> +printf ("dhcpc: realloc failed (%s:%d)", __FILE__, __LINE__);
> +free (dhcp_hostname);
> +dhcp_hostname = NULL;
> + }
> +} else { /* dhcp_hostname == NULL */
>dhcp_hostname = strndup (p, len);
> +}
> break;
>
>case 7:
> --
> 2.5.1
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH 4/4] score: Implement priority boosting
3 and 4 look good.
On Thu, Sep 3, 2015 at 8:01 AM, Sebastian Huber
wrote:
> ---
> cpukit/score/include/rtems/score/threadimpl.h | 31 +
> cpukit/score/include/rtems/score/threadqimpl.h | 25 +++
> cpukit/score/src/coremutexseize.c | 2 +-
> cpukit/score/src/coremutexsurrender.c | 1 +
> cpukit/score/src/mutex.c | 15 ---
> cpukit/score/src/threadchangepriority.c| 34 ++
> cpukit/score/src/threadqops.c | 22 ++
> doc/user/sem.t | 5 +++
> doc/user/smp.t | 6 ++-
> testsuites/smptests/smpmutex01/init.c | 61
> +++---
> 10 files changed, 189 insertions(+), 13 deletions(-)
>
> diff --git a/cpukit/score/include/rtems/score/threadimpl.h
> b/cpukit/score/include/rtems/score/threadimpl.h
> index 4656881..1092b65 100644
> --- a/cpukit/score/include/rtems/score/threadimpl.h
> +++ b/cpukit/score/include/rtems/score/threadimpl.h
> @@ -437,6 +437,37 @@ void _Thread_Raise_priority(
> );
>
> /**
> + * @brief Inherit the priority of a thread.
> + *
> + * It changes the current priority of the inheritor thread to the current
> priority
> + * of the ancestor thread if it is higher than the current priority of the
> inheritor
> + * thread. In this case the inheritor thread is appended to its new
> priority group
> + * in its scheduler instance.
> + *
> + * On SMP configurations, the priority is changed to PRIORITY_PSEUDO_ISR in
> + * case the own schedulers of the inheritor and ancestor thread differ
> (priority
> + * boosting).
> + *
> + * @param[in] inheritor The thread to inherit the priority.
> + * @param[in] ancestor The thread to bequeath its priority to the inheritor
> + * thread.
> + */
> +#if defined(RTEMS_SMP)
> +void _Thread_Inherit_priority(
> + Thread_Control *inheritor,
> + Thread_Control *ancestor
> +);
> +#else
> +RTEMS_INLINE_ROUTINE void _Thread_Inherit_priority(
> + Thread_Control *inheritor,
> + Thread_Control *ancestor
> +)
> +{
> + _Thread_Raise_priority( inheritor, ancestor->current_priority );
> +}
> +#endif
> +
> +/**
> * @brief Sets the current to the real priority of a thread.
> *
> * Sets the priority restore hint to false.
> diff --git a/cpukit/score/include/rtems/score/threadqimpl.h
> b/cpukit/score/include/rtems/score/threadqimpl.h
> index bf01eb7..510f886 100644
> --- a/cpukit/score/include/rtems/score/threadqimpl.h
> +++ b/cpukit/score/include/rtems/score/threadqimpl.h
> @@ -522,6 +522,31 @@ RTEMS_INLINE_ROUTINE void _Thread_queue_Destroy(
> }
>
> /**
> + * @brief Boosts the priority of the thread if threads of another scheduler
> + * instance are enqueued on the thread queue.
> + *
> + * The thread queue must use the priority waiting discipline.
> + *
> + * @param[in] queue The actual thread queue.
> + * @param[in] the_thread The thread to boost the priority if necessary.
> + */
> +#if defined(RTEMS_SMP)
> +void _Thread_queue_Boost_priority(
> + Thread_queue_Queue *queue,
> + Thread_Control *the_thread
> +);
> +#else
> +RTEMS_INLINE_ROUTINE void _Thread_queue_Boost_priority(
> + Thread_queue_Queue *queue,
> + Thread_Control *the_thread
> +)
> +{
> + (void) queue;
> + (void) the_thread;
> +}
> +#endif
> +
> +/**
> * @brief Compare two thread's priority for RBTree Insertion.
> *
> * @param[in] left points to the left thread's RBnode
> diff --git a/cpukit/score/src/coremutexseize.c
> b/cpukit/score/src/coremutexseize.c
> index ddc5d6b..8059659 100644
> --- a/cpukit/score/src/coremutexseize.c
> +++ b/cpukit/score/src/coremutexseize.c
> @@ -75,7 +75,7 @@ void _CORE_mutex_Seize_interrupt_blocking(
> _Thread_queue_Release( &the_mutex->Wait_queue, lock_context );
> #endif
>
> -_Thread_Raise_priority( holder, executing->current_priority );
> +_Thread_Inherit_priority( holder, executing );
>
> #if !defined(RTEMS_SMP)
> _Thread_queue_Acquire( &the_mutex->Wait_queue, lock_context );
> diff --git a/cpukit/score/src/coremutexsurrender.c
> b/cpukit/score/src/coremutexsurrender.c
> index d3f965d..7d9c57f 100644
> --- a/cpukit/score/src/coremutexsurrender.c
> +++ b/cpukit/score/src/coremutexsurrender.c
> @@ -209,6 +209,7 @@ CORE_mutex_Status _CORE_mutex_Surrender(
> case CORE_MUTEX_DISCIPLINES_PRIORITY_INHERIT:
>_CORE_mutex_Push_priority( the_mutex, the_thread );
>the_thread->resource_count++;
> + _Thread_queue_Boost_priority( &the_mutex->Wait_queue.Queue,
> the_thread );
>break;
> case CORE_MUTEX_DISCIPLINES_PRIORITY_CEILING:
>_CORE_mutex_Push_priority( the_mutex, the_thread );
> diff --git a/cpukit/score/src/mutex.c b/cpukit/score/src/mutex.c
> index ae637dd..f03bab7 100644
> --- a/cpukit/score/src/mutex.c
> +++ b/cpukit/score/src/mutex.c
> @@ -112,9 +112,7 @@ static void _Mutex_Acquire_slow(
>ISR_lock_Context *lock_context
> )
> {
> - /* Priority
Re: [PATCH] RTEMS CAN Rough Draft Implementation
This is on my list but I'm back-logged. Hopefully someone else can check through it, preferably someone who is knowledgeable about CAN. :) On Thu, Aug 27, 2015 at 2:45 PM, Isaac Gutekunst wrote: > Hi All, > > Here is the RTEMS CAN driver framework I've been talking about. Please give > me feedback, and don't worry about being harsh. I want to commit something > of value. > > > Concerns > > > * Usage of return codes. > * General higher level error handling. > * Changing can bit rate. > * In general, changing CAN parameters at runtime. > * Task model: Should there really be an RX and TX task required by the RTEMS > driver? Is the method of starting and stopping tasks acceptable? > > The motivation for this is that the CAN controller we are using, (STM32 > BxCAN) requires you to re-initialize the device to change parameters. This > is a bit awkward with first calling open, and then IOCTL to configure the > bus. Any thoughts? > > Thanks, > > Isaac > > > P.S. I'm having trouble with git send-email. Something is not quite right > with our mail server here. I've attached the patch instead. > > -- > Isaac Gutekunst > Embedded Systems Software Engineer > isaac.guteku...@vecna.com > www.vecna.com > > ___ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH v2 3/5] tools/cpu/nios2/ptf.c: Fix leak of memory pointed to by new_prefix
Am I misreading this or did the formatting change?
It looks like the indentation on the "+" lines is different
On 9/2/2015 4:54 PM, Martin Galvan wrote:
Updates #2405.
---
tools/cpu/nios2/ptf.c | 24 ++--
1 file changed, 14 insertions(+), 10 deletions(-)
diff --git a/tools/cpu/nios2/ptf.c b/tools/cpu/nios2/ptf.c
index 7a31c11..07d6183 100644
--- a/tools/cpu/nios2/ptf.c
+++ b/tools/cpu/nios2/ptf.c
@@ -567,17 +567,21 @@ void ptf_printf(FILE *s, struct ptf *tree, char *prefix)
new_prefix_len += strlen(leaf->value) + 1;
};
new_prefix = (char *)malloc(new_prefix_len);
-strcpy(new_prefix, prefix);
-strcat(new_prefix, leaf->name);
-if(leaf->value != NULL && leaf->value[0] != 0)
+if (new_prefix != NULL)
{
- strcat(new_prefix, ":");
- strcat(new_prefix, leaf->value);
-};
-strcat(new_prefix, "/");
-fputs(new_prefix, s);
-fputs("\n", s);
-ptf_printf(s, leaf->sub, new_prefix);
+ strcpy(new_prefix, prefix);
+ strcat(new_prefix, leaf->name);
+ if(leaf->value != NULL && leaf->value[0] != 0)
+ {
+strcat(new_prefix, ":");
+strcat(new_prefix, leaf->value);
+ };
+ strcat(new_prefix, "/");
+ fputs(new_prefix, s);
+ fputs("\n", s);
+ ptf_printf(s, leaf->sub, new_prefix);
+ free(new_prefix);
+}
break;
};
--
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherr...@oarcorp.comOn-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL 35805
Support Available(256) 722-9985
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH v2 4/5] cpukit/libmisc/dumpbuf/dumpbuf.c: Fix undefined behavior for sprintf()
On 9/2/2015 4:54 PM, Martin Galvan wrote:
I also used the 'n' versions of the string functions, #define'd magic numbers
and added a few comments.
Great on the 'n' versions!
One comment. Why is the output buffer now static? I know it
moves it off the stack but what's the consensus on an 80
byte array on a stack?
Updates #2405.
---
cpukit/libmisc/dumpbuf/dumpbuf.c | 121 ---
1 file changed, 75 insertions(+), 46 deletions(-)
diff --git a/cpukit/libmisc/dumpbuf/dumpbuf.c b/cpukit/libmisc/dumpbuf/dumpbuf.c
index 9d34d42..bb63997 100644
--- a/cpukit/libmisc/dumpbuf/dumpbuf.c
+++ b/cpukit/libmisc/dumpbuf/dumpbuf.c
@@ -6,7 +6,7 @@
*/
/*
- * COPYRIGHT (c) 1997-2007.
+ * COPYRIGHT (c) 1997-2015.
* On-Line Applications Research Corporation (OAR).
*
* The license and distribution terms for this file may in
@@ -24,62 +24,91 @@
#include
#include
+#define HEX_FMT_LENGTH 3 /* Length of the formatted hex string. */
+#define ASCII_FMT_LENGTH 1 /* Length of the formatted ASCII string. */
+#define BYTES_PER_ROW 16/* Amount of bytes from buffer shown in each row.
*/
+#define BARS 2 /* Amount of bars in each row. */
+/* Max length of each row string. */
+#define ROW_LENGTH (BYTES_PER_ROW * (HEX_FMT_LENGTH + ASCII_FMT_LENGTH) + BARS)
+
/*
* Put the body below rtems_print_buffer so it won't get inlined.
*/
-static inline void Dump_Line(
- const unsigned char *buffer,
- int length
-);
+static void Dump_Line(const unsigned char *buffer, const unsigned int length);
-void rtems_print_buffer(
- const unsigned char *buffer,
- int length
-)
+/**
+ * @brief Print \p length bytes from \p buffer, both in hex and ASCII.
+ * Printing will be done in rows, each showing BYTES_PER_ROW bytes.
+ * @details Non-printable chars will appear as dots.
+ *
+ * @param buffer The buffer we'll print.
+ * @param length Amount of bytes from \p buffer we'll print. This can't be
+ * unsigned because we don't have a way to check if we're erroneously getting
+ * a negative \p length.
+ */
+void rtems_print_buffer(const unsigned char *buffer, const int length)
{
+ unsigned int i, mod, max;
- int i, mod, max;
-
- if ( !length ) return;
+ if (length > 0) {
+mod = length % BYTES_PER_ROW;
- mod = length % 16;
+max = length - mod;
- max = length - mod;
+/* Print length / BYTES_PER_ROW rows. */
+for (i = 0; i < max; i += BYTES_PER_ROW) {
+ Dump_Line(&buffer[i], BYTES_PER_ROW);
+}
- for ( i=0 ; i 0) {
+ Dump_Line(&buffer[max], mod);
+}
+ } else {
+printk("Error: length must be greater than zero.");
+ }
}
-static inline void Dump_Line(
- const unsigned char *buffer,
- int length
-)
+/**
+ * @brief Print \p length bytes from \p buffer, both in hex and ASCII.
+ * @details Non-printable chars will appear as dots.
+ *
+ * @param buffer The buffer we'll print.
+ * @param length Amount of bytes from \p buffer we'll print.
+ */
+static void Dump_Line(const unsigned char *buffer, const unsigned int length)
{
-
- int i;
- char line_buffer[120];
-
- line_buffer[0] = '\0';
-
- for( i=0 ; i
--
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherr...@oarcorp.comOn-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL 35805
Support Available(256) 722-9985
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH v2 1/5] various .h files: Add missing C++ extern wrappers
I committed 1, 2, and 5 to 4.11 and master. The ticket closed
with 5. Once the questions about 3 and 4 are answered, then
I will apply those.
On 9/2/2015 4:54 PM, Martin Galvan wrote:
Updates #2405.
---
c/src/lib/libbsp/shared/umon/umon.h | 4
cpukit/posix/include/rtems/posix/ptimer.h| 5 -
cpukit/rtems/include/rtems/rtems/dpmemimpl.h | 6 +-
3 files changed, 13 insertions(+), 2 deletions(-)
diff --git a/c/src/lib/libbsp/shared/umon/umon.h
b/c/src/lib/libbsp/shared/umon/umon.h
index 3c5bdf9..d25a781 100644
--- a/c/src/lib/libbsp/shared/umon/umon.h
+++ b/c/src/lib/libbsp/shared/umon/umon.h
@@ -61,4 +61,8 @@ int rtems_initialize_tfs_filesystem(
*/
int umoncons_poll_read(int minor);
+#ifdef __cplusplus
+}
#endif
+
+#endif /* __rtems_umon_h */
diff --git a/cpukit/posix/include/rtems/posix/ptimer.h
b/cpukit/posix/include/rtems/posix/ptimer.h
index 7cc0516..16ac2b8 100644
--- a/cpukit/posix/include/rtems/posix/ptimer.h
+++ b/cpukit/posix/include/rtems/posix/ptimer.h
@@ -87,6 +87,9 @@ int timer_getoverrun(
timer_t timerid
);
+#ifdef __cplusplus
+}
+#endif
/** @} */
-#endif
+#endif /* _RTEMS_POSIX_PTIMER_H */
diff --git a/cpukit/rtems/include/rtems/rtems/dpmemimpl.h
b/cpukit/rtems/include/rtems/rtems/dpmemimpl.h
index 9fd2e6c..3e0c231 100644
--- a/cpukit/rtems/include/rtems/rtems/dpmemimpl.h
+++ b/cpukit/rtems/include/rtems/rtems/dpmemimpl.h
@@ -20,6 +20,10 @@
#include
#include
+#ifdef __cplusplus
+extern "C" {
+#endif
+
/**
* @defgroup ClassicDPMEMImpl Dual Ported Memory Manager Implementation
*
@@ -104,5 +108,5 @@ RTEMS_INLINE_ROUTINE Dual_ported_memory_Control
*_Dual_ported_memory_Get (
}
#endif
-#endif
+#endif /* _RTEMS_RTEMS_DPMEM_INL */
/* end of include file */
--
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherr...@oarcorp.comOn-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL 35805
Support Available(256) 722-9985
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH v2 3/5] tools/cpu/nios2/ptf.c: Fix leak of memory pointed to by new_prefix
On Thu, Sep 3, 2015 at 1:20 PM, Joel Sherrill wrote:
> Am I misreading this or did the formatting change?
>
> It looks like the indentation on the "+" lines is different
Indeed :) Now the '+' lines are executed only if new_prefix != NULL
(new_prefix being the result of malloc). The resulting code looks like
this:
new_prefix = (char *)malloc(new_prefix_len);
if (new_prefix != NULL)
{
strcpy(new_prefix, prefix);
strcat(new_prefix, leaf->name);
if(leaf->value != NULL && leaf->value[0] != 0)
{
strcat(new_prefix, ":");
strcat(new_prefix, leaf->value);
};
strcat(new_prefix, "/");
fputs(new_prefix, s);
fputs("\n", s);
ptf_printf(s, leaf->sub, new_prefix);
free(new_prefix);
}
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH v2 4/5] cpukit/libmisc/dumpbuf/dumpbuf.c: Fix undefined behavior for sprintf()
On Thu, Sep 3, 2015 at 1:21 PM, Joel Sherrill wrote: > One comment. Why is the output buffer now static? I know it > moves it off the stack but what's the consensus on an 80 > byte array on a stack? I'm not sure what the consensus is. I briefly discussed this with Daniel and it's ok with us, but it's really your call. Is this part of the target binary, or is it a host util? If it runs on the host, maybe we can consider leaving it in the stack. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH v2 4/5] cpukit/libmisc/dumpbuf/dumpbuf.c: Fix undefined behavior for sprintf()
On Thu, Sep 3, 2015 at 1:21 PM, Joel Sherrill wrote:
>
>
> On 9/2/2015 4:54 PM, Martin Galvan wrote:
>>
>> I also used the 'n' versions of the string functions, #define'd magic
>> numbers
>> and added a few comments.
>
>
> Great on the 'n' versions!
>
> One comment. Why is the output buffer now static? I know it
> moves it off the stack but what's the consensus on an 80
> byte array on a stack?
There are some reasons:
1) out of the stack, here, means that it will be moved as a static
memory. If it doesn't fit, the toolchain will warn.
2) we don't know how much stack memory is left. This is specially
important in a debugging function which
could be called in a faulty context.
3) 80 bytes is not that low.
>
>
>>
>> Updates #2405.
>> ---
>> cpukit/libmisc/dumpbuf/dumpbuf.c | 121
>> ---
>> 1 file changed, 75 insertions(+), 46 deletions(-)
>>
>> diff --git a/cpukit/libmisc/dumpbuf/dumpbuf.c
>> b/cpukit/libmisc/dumpbuf/dumpbuf.c
>> index 9d34d42..bb63997 100644
>> --- a/cpukit/libmisc/dumpbuf/dumpbuf.c
>> +++ b/cpukit/libmisc/dumpbuf/dumpbuf.c
>> @@ -6,7 +6,7 @@
>>*/
>>
>> /*
>> - * COPYRIGHT (c) 1997-2007.
>> + * COPYRIGHT (c) 1997-2015.
>>* On-Line Applications Research Corporation (OAR).
>>*
>>* The license and distribution terms for this file may in
>> @@ -24,62 +24,91 @@
>> #include
>> #include
>>
>> +#define HEX_FMT_LENGTH 3 /* Length of the formatted hex string. */
>> +#define ASCII_FMT_LENGTH 1 /* Length of the formatted ASCII string. */
>> +#define BYTES_PER_ROW 16/* Amount of bytes from buffer shown in each
>> row. */
>> +#define BARS 2 /* Amount of bars in each row. */
>> +/* Max length of each row string. */
>> +#define ROW_LENGTH (BYTES_PER_ROW * (HEX_FMT_LENGTH + ASCII_FMT_LENGTH) +
>> BARS)
>> +
>> /*
>>* Put the body below rtems_print_buffer so it won't get inlined.
>>*/
>>
>> -static inline void Dump_Line(
>> - const unsigned char *buffer,
>> - int length
>> -);
>> +static void Dump_Line(const unsigned char *buffer, const unsigned int
>> length);
>>
>> -void rtems_print_buffer(
>> - const unsigned char *buffer,
>> - int length
>> -)
>> +/**
>> + * @brief Print \p length bytes from \p buffer, both in hex and ASCII.
>> + * Printing will be done in rows, each showing BYTES_PER_ROW bytes.
>> + * @details Non-printable chars will appear as dots.
>> + *
>> + * @param buffer The buffer we'll print.
>> + * @param length Amount of bytes from \p buffer we'll print. This can't
>> be
>> + * unsigned because we don't have a way to check if we're erroneously
>> getting
>> + * a negative \p length.
>> + */
>> +void rtems_print_buffer(const unsigned char *buffer, const int length)
>> {
>> + unsigned int i, mod, max;
>>
>> - int i, mod, max;
>> -
>> - if ( !length ) return;
>> + if (length > 0) {
>> +mod = length % BYTES_PER_ROW;
>>
>> - mod = length % 16;
>> +max = length - mod;
>>
>> - max = length - mod;
>> +/* Print length / BYTES_PER_ROW rows. */
>> +for (i = 0; i < max; i += BYTES_PER_ROW) {
>> + Dump_Line(&buffer[i], BYTES_PER_ROW);
>> +}
>>
>> - for ( i=0 ; i> -Dump_Line( &buffer[ i ], 16 );
>> -
>> - if ( mod )
>> -Dump_Line( &buffer[ max ], mod );
>> +/* Print another row with the remaining bytes. */
>> +if (mod > 0) {
>> + Dump_Line(&buffer[max], mod);
>> +}
>> + } else {
>> +printk("Error: length must be greater than zero.");
>> + }
>> }
>>
>> -static inline void Dump_Line(
>> - const unsigned char *buffer,
>> - int length
>> -)
>> +/**
>> + * @brief Print \p length bytes from \p buffer, both in hex and ASCII.
>> + * @details Non-printable chars will appear as dots.
>> + *
>> + * @param buffer The buffer we'll print.
>> + * @param length Amount of bytes from \p buffer we'll print.
>> + */
>> +static void Dump_Line(const unsigned char *buffer, const unsigned int
>> length)
>> {
>> -
>> - int i;
>> - char line_buffer[120];
>> -
>> - line_buffer[0] = '\0';
>> -
>> - for( i=0 ; i> -sprintf( line_buffer, "%s%02x ", line_buffer, buffer[ i ] );
>> -
>> - for( ; i<16 ; i++ )
>> -strcat( line_buffer, " " );
>> -
>> - strcat( line_buffer, "|" );
>> - for( i=0 ; i> -sprintf( line_buffer, "%s%c", line_buffer,
>> - isprint( buffer[ i ] ) ? buffer[ i ] : '.' );
>> -
>> - for( ; i<16 ; i++ )
>> -strcat( line_buffer, " " );
>> -
>> - strcat( line_buffer, "|\n" );
>> -
>> - printk( line_buffer );
>> + unsigned int i;
>> + static unsigned char line_buffer[ROW_LENGTH] = "";
>> + size_t tmp_len;
>> +
>> + /* Output the hex value of each byte. */
>> + for (i = 0; i < length; ++i) {
>> +snprintf(&line_buffer[i * HEX_FMT_LENGTH], HEX_FMT_LENGTH + 1,
>> + "%02x ", buffer[i]);
>> + }
>> +
>> + /* Fill the remaining space with whitespace (if necessary). */
>> + for (; i < BYTES_PER_ROW; ++i) {
>> +strncat(line_buffer, " "
Re: [PATCH v2 4/5] cpukit/libmisc/dumpbuf/dumpbuf.c: Fix undefined behavior for sprintf()
On 9/3/2015 12:18 PM, Daniel Gutson wrote:
On Thu, Sep 3, 2015 at 1:21 PM, Joel Sherrill wrote:
On 9/2/2015 4:54 PM, Martin Galvan wrote:
I also used the 'n' versions of the string functions, #define'd magic
numbers
and added a few comments.
Great on the 'n' versions!
One comment. Why is the output buffer now static? I know it
moves it off the stack but what's the consensus on an 80
byte array on a stack?
There are some reasons:
1) out of the stack, here, means that it will be moved as a static
memory. If it doesn't fit, the toolchain will warn.
2) we don't know how much stack memory is left. This is specially
important in a debugging function which
could be called in a faulty context.
3) 80 bytes is not that low.
It is a target side utility to print memory in a format similar
to many ROM monitors.
I agree with everything you said and I forget how tiny the RAM
is on some of the new CPUs. I suppose always having it accounted
for is safer than having it as a transient on the stack value.
If you had 512 byte stacks which is feasible for some applications,
you wouldn't want 80 taken by this. But I am also not sure how
much stack calling snprintf() uses either. :)
I'm going to apply this and the other patch. Certainly we
didn't make anything worse.
--joel
Updates #2405.
---
cpukit/libmisc/dumpbuf/dumpbuf.c | 121
---
1 file changed, 75 insertions(+), 46 deletions(-)
diff --git a/cpukit/libmisc/dumpbuf/dumpbuf.c
b/cpukit/libmisc/dumpbuf/dumpbuf.c
index 9d34d42..bb63997 100644
--- a/cpukit/libmisc/dumpbuf/dumpbuf.c
+++ b/cpukit/libmisc/dumpbuf/dumpbuf.c
@@ -6,7 +6,7 @@
*/
/*
- * COPYRIGHT (c) 1997-2007.
+ * COPYRIGHT (c) 1997-2015.
* On-Line Applications Research Corporation (OAR).
*
* The license and distribution terms for this file may in
@@ -24,62 +24,91 @@
#include
#include
+#define HEX_FMT_LENGTH 3 /* Length of the formatted hex string. */
+#define ASCII_FMT_LENGTH 1 /* Length of the formatted ASCII string. */
+#define BYTES_PER_ROW 16/* Amount of bytes from buffer shown in each
row. */
+#define BARS 2 /* Amount of bars in each row. */
+/* Max length of each row string. */
+#define ROW_LENGTH (BYTES_PER_ROW * (HEX_FMT_LENGTH + ASCII_FMT_LENGTH) +
BARS)
+
/*
* Put the body below rtems_print_buffer so it won't get inlined.
*/
-static inline void Dump_Line(
- const unsigned char *buffer,
- int length
-);
+static void Dump_Line(const unsigned char *buffer, const unsigned int
length);
-void rtems_print_buffer(
- const unsigned char *buffer,
- int length
-)
+/**
+ * @brief Print \p length bytes from \p buffer, both in hex and ASCII.
+ * Printing will be done in rows, each showing BYTES_PER_ROW bytes.
+ * @details Non-printable chars will appear as dots.
+ *
+ * @param buffer The buffer we'll print.
+ * @param length Amount of bytes from \p buffer we'll print. This can't
be
+ * unsigned because we don't have a way to check if we're erroneously
getting
+ * a negative \p length.
+ */
+void rtems_print_buffer(const unsigned char *buffer, const int length)
{
+ unsigned int i, mod, max;
- int i, mod, max;
-
- if ( !length ) return;
+ if (length > 0) {
+mod = length % BYTES_PER_ROW;
- mod = length % 16;
+max = length - mod;
- max = length - mod;
+/* Print length / BYTES_PER_ROW rows. */
+for (i = 0; i < max; i += BYTES_PER_ROW) {
+ Dump_Line(&buffer[i], BYTES_PER_ROW);
+}
- for ( i=0 ; i 0) {
+ Dump_Line(&buffer[max], mod);
+}
+ } else {
+printk("Error: length must be greater than zero.");
+ }
}
-static inline void Dump_Line(
- const unsigned char *buffer,
- int length
-)
+/**
+ * @brief Print \p length bytes from \p buffer, both in hex and ASCII.
+ * @details Non-printable chars will appear as dots.
+ *
+ * @param buffer The buffer we'll print.
+ * @param length Amount of bytes from \p buffer we'll print.
+ */
+static void Dump_Line(const unsigned char *buffer, const unsigned int
length)
{
-
- int i;
- char line_buffer[120];
-
- line_buffer[0] = '\0';
-
- for( i=0 ; i
--
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherr...@oarcorp.comOn-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL 35805
Support Available(256) 722-9985
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
--
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherr...@oarcorp.comOn-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL 35805
Support Available(256) 722-9985
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCH] cpukit/libnetworking/rtems/rtems_dhcp.c: Fix compilation error
Apparently 'free' is defined as a macro which takes two arguments and calls
rtems_bsdnet_free. When fixing #2405 I added a missing 'free' but didn't notice
it was non-standard.
Closes #2410.
---
cpukit/libnetworking/rtems/rtems_dhcp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/cpukit/libnetworking/rtems/rtems_dhcp.c
b/cpukit/libnetworking/rtems/rtems_dhcp.c
index 87be238..cb6966d 100644
--- a/cpukit/libnetworking/rtems/rtems_dhcp.c
+++ b/cpukit/libnetworking/rtems/rtems_dhcp.c
@@ -405,7 +405,7 @@ process_options (unsigned char *optbuf, int optbufSize)
strncpy (dhcp_hostname, p, len);
} else { /* realloc failed */
printf ("dhcpc: realloc failed (%s:%d)", __FILE__, __LINE__);
-free (dhcp_hostname);
+free (dhcp_hostname, 0);
dhcp_hostname = NULL;
}
} else { /* dhcp_hostname == NULL */
--
2.5.1
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] cpukit/libnetworking/rtems/rtems_dhcp.c: Fix compilation error
Should be committed now.
I guess one of us should have compiled it. :)
--joel
On 9/3/2015 3:25 PM, Martin Galvan wrote:
Apparently 'free' is defined as a macro which takes two arguments and calls
rtems_bsdnet_free. When fixing #2405 I added a missing 'free' but didn't notice
it was non-standard.
Closes #2410.
---
cpukit/libnetworking/rtems/rtems_dhcp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/cpukit/libnetworking/rtems/rtems_dhcp.c
b/cpukit/libnetworking/rtems/rtems_dhcp.c
index 87be238..cb6966d 100644
--- a/cpukit/libnetworking/rtems/rtems_dhcp.c
+++ b/cpukit/libnetworking/rtems/rtems_dhcp.c
@@ -405,7 +405,7 @@ process_options (unsigned char *optbuf, int optbufSize)
strncpy (dhcp_hostname, p, len);
} else { /* realloc failed */
printf ("dhcpc: realloc failed (%s:%d)", __FILE__, __LINE__);
-free (dhcp_hostname);
+free (dhcp_hostname, 0);
dhcp_hostname = NULL;
}
} else { /* dhcp_hostname == NULL */
--
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherr...@oarcorp.comOn-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL 35805
Support Available(256) 722-9985
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCH] cpukit/libmisc/dumpbuf/dumpbuf.c: Fix compilation warnings
Compiling dumpbuf.c causes the following warning to be issued:
warning: pointer targets in passing argument 1 of 'snprintf' differ in
signedness [-Wpointer-sign]
This happens because line_buffer is declared as unsigned.
Closes #2411.
---
cpukit/libmisc/dumpbuf/dumpbuf.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/cpukit/libmisc/dumpbuf/dumpbuf.c b/cpukit/libmisc/dumpbuf/dumpbuf.c
index bb63997..2f2cd10 100644
--- a/cpukit/libmisc/dumpbuf/dumpbuf.c
+++ b/cpukit/libmisc/dumpbuf/dumpbuf.c
@@ -80,7 +80,7 @@ void rtems_print_buffer(const unsigned char *buffer, const
int length)
static void Dump_Line(const unsigned char *buffer, const unsigned int length)
{
unsigned int i;
- static unsigned char line_buffer[ROW_LENGTH] = "";
+ static char line_buffer[ROW_LENGTH] = "";
size_t tmp_len;
/* Output the hex value of each byte. */
--
2.5.1
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] cpukit/libnetworking/rtems/rtems_dhcp.c: Fix compilation error
On Thu, Sep 3, 2015 at 5:44 PM, Joel Sherrill wrote:
> Should be committed now.
>
> I guess one of us should have compiled it. :)
Don't worry, Martin will buy some beers because of this.
Cheers.
Daniel.
>
> --joel
>
> On 9/3/2015 3:25 PM, Martin Galvan wrote:
>>
>> Apparently 'free' is defined as a macro which takes two arguments and
>> calls
>> rtems_bsdnet_free. When fixing #2405 I added a missing 'free' but didn't
>> notice
>> it was non-standard.
>>
>> Closes #2410.
>> ---
>> cpukit/libnetworking/rtems/rtems_dhcp.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/cpukit/libnetworking/rtems/rtems_dhcp.c
>> b/cpukit/libnetworking/rtems/rtems_dhcp.c
>> index 87be238..cb6966d 100644
>> --- a/cpukit/libnetworking/rtems/rtems_dhcp.c
>> +++ b/cpukit/libnetworking/rtems/rtems_dhcp.c
>> @@ -405,7 +405,7 @@ process_options (unsigned char *optbuf, int
>> optbufSize)
>> strncpy (dhcp_hostname, p, len);
>> } else { /* realloc failed */
>> printf ("dhcpc: realloc failed (%s:%d)", __FILE__,
>> __LINE__);
>> -free (dhcp_hostname);
>> +free (dhcp_hostname, 0);
>> dhcp_hostname = NULL;
>> }
>> } else { /* dhcp_hostname == NULL */
>>
>
> --
> Joel Sherrill, Ph.D. Director of Research & Development
> joel.sherr...@oarcorp.comOn-Line Applications Research
> Ask me about RTEMS: a free RTOS Huntsville AL 35805
> Support Available(256) 722-9985
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
--
Daniel F. Gutson
Chief Engineering Officer, SPD
San Lorenzo 47, 3rd Floor, Office 5
Córdoba, Argentina
Phone: +54 351 4217888 / +54 351 4218211
Skype:dgutson
LinkedIn: http://ar.linkedin.com/in/danielgutson
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[wwwdocs] GCC 6 Release Notes for RTEMS
Index: htdocs/gcc-6/changes.html === RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-6/changes.html,v retrieving revision 1.25 diff -u -r1.25 changes.html --- htdocs/gcc-6/changes.html 25 Aug 2015 22:27:46 - 1.25 +++ htdocs/gcc-6/changes.html 4 Sep 2015 06:21:14 - @@ -203,6 +203,23 @@ + + +The RTEMS thread model implementation changed. For the mutexes +self-contained objects defined in Newlibare used +instead of Classic API semaphores. The keys for thread specific data and +the once function are directly defined via . +Self-contained condition variables are provided via Newlib + . The RTEMS thread model supports now the C++11 +threads. + +The OpenMP support uses now self-contained objects provided by Newlib + and offers a significantly better performance compared +to the POSIX configuration of libgomp. It is possible to +configure thread pools for each scheduler instance via the environment +variable GOMP_RTEMS_THREAD_POOLS. + + -- 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
Re: [PATCH 1/4] smp: Documentation
On 03/09/15 16:59, Gedare Bloom wrote:
On Thu, Sep 3, 2015 at 8:01 AM, Sebastian Huber
wrote:
>---
> doc/user/smp.t | 38 ++
> 1 file changed, 38 insertions(+)
>
>diff --git a/doc/user/smp.t b/doc/user/smp.t
>index 1b4849a..ba700e0 100644
>--- a/doc/user/smp.t
>+++ b/doc/user/smp.t
>@@ -147,6 +147,44 @@ another processor. So if we enable interrupts during
this transition we have
> to provide an alternative task independent stack for this time frame. This
> issue needs further investigation.
>
>+@subsection Clustered/Partitioned Scheduling
>+
>+We have clustered scheduling in case the set of processors of a system is
>+partitioned into non-empty pairwise-disjoint subsets. These subsets are called
>+clusters. Clusters with a cardinality of one are partitions. Each cluster is
>+owned by exactly one scheduler instance.
>+
>+Clustered/partitioned scheduling helps to control the worst-case latencies in
>+the system, see @cite{Brandenburg, Björn B.: Scheduling and Locking in
>+Multiprocessor Real-Time Operating Systems. PhD thesis, 2011.
>+@uref{http://www.cs.unc.edu/~bbb/diss/brandenburg-diss.pdf}}. The goal is to
>+reduce the amount of shared state in the system and thus prevention of lock
>+contention. Modern multi-processor systems tend to have several layers of data
>+and instruction caches. With clustered/partitioned scheduling it is possible
to
>+honour the cache topology of a system and thus avoid expensive cache
>+synchronization traffic. It is easy to implement. The problem is to provide
>+synchronization primitives for inter-partition synchronization. In RTEMS there
>+are currently three means available
>+
>+@itemize @bullet
>+@item events,
>+@item message queues, and
>+@item semaphores using the @ref{Semaphore Manager Multiprocessor Resource
>+Sharing Protocol} (MrsP).
>+@end itemize
>+
>+The clustered/partitioned scheduling approach enables separation of functions
>+with real-time requirements and functions that profit from fairness and high
>+throughput provided the scheduler instances are fully decoupled and adequate
>+intra-partition synchronization primitives are used. This is work in
progress.
inter-partition? inter-partition doesn't make sense. Also, to be
general, it should really be inter-cluster, which goes for the above
use of "inter-partition" as well. Because of the use of partition in
Partitioned Scheduling, we have to be careful about the use of
partition in other places related to SMP scheduling, unfortunately.
Would it be better to replace "clustered/partitioned scheduling" with
"clustered scheduling" throughout the manual and just mention that
partitions are clusters with exactly one processor? So we have
"inter-cluster synchronization" for synchronization that involves more
than more cluster and "intra-cluster synchronization" for
synchronization that involves exactly one cluster.
--
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
Re: [PATCH] smp: Documentation
On 03/09/15 17:09, Gedare Bloom wrote:
On Thu, Sep 3, 2015 at 8:46 AM, Sebastian Huber
wrote:
---
doc/user/smp.t | 66 ++
1 file changed, 66 insertions(+)
diff --git a/doc/user/smp.t b/doc/user/smp.t
index 2ab9aaf..a06be8a 100644
--- a/doc/user/smp.t
+++ b/doc/user/smp.t
@@ -465,6 +465,72 @@ architecture please consult the @cite{RTEMS CPU
Architecture Supplement}.
The only remaining user of task variables in the RTEMS code base is the Ada
support. So basically Ada is not available on RTEMS SMP.
+@subsection OpenMP
+
+OpenMP support for RTEMS is available via the GCC provided libgomp. There is
+libgomp support for RTEMS in the POSIX configuration since GCC 4.9 (requires a
+Newlib snapshot after 2015-03-12). In GCC 6.1 or later (requires a Newlib
+snapshot after 2015-07-30 for provided self-contained
Do these versions relate to any release versions of RTEMS, e.g. did
this stuff make it into the toolchains for 4.11? Translating between
gcc/newlib versions and RTEMS versions is a bit of work for casual
user to know if this support will be available or not for them.
In case the manual includes this section, then its supported by RTEMS.
It helps to check if you use the right tool chain version. In general it
would be nice to collect such information in a well known central place.
+synchronization objects) there is RTEMS support in a RTEMS specific
hyphenate: "RTEMS-specific" here and below.
+configuration which offers a significantly better performance compared to the
"libgomp configuration"
+POSIX configuration (the term configuration refers here to the libgomp
+configuration and should not be confused with the POSIX API provided by RTEMS).
+In addition scheduler instance specific thread pools may be defined.
Last sentence doesn't say why that matters. Perhaps just say something
about discussing this further below.
Hm, I wanted to say that the thread pools are new in GCC 6.1 and not
available before.
+
+The run-time configuration of libgomp is done via environment variables
+documented in the @uref{https://gcc.gnu.org/onlinedocs/libgomp/, libgomp
+manual}. The environment variables are evaluated in a constructor function
+which executes in the context of the first initialization task before the
+actual initialization task function is called (just like a global C++
+constructor). To set application specific values, a higher priority
hyphenate: "application-specific"
+constructor function must be used to set up the environment variables.
+
+@example
+@group
+#include
+
+static void __attribute__((constructor(1000))) config_libgomp( void )
+@{
+ setenv( "OMP_DISPLAY_ENV", "VERBOSE", 1 );
+ setenv( "GOMP_SPINCOUNT", "3", 1 );
+ setenv( "GOMP_RTEMS_THREAD_POOLS", "1$2@@SCHD", 1 );
+@}
+@end group
+@end example
+
The following discussion may warrant it's own subsection on Thread Pools.
+The environment variable @env{GOMP_RTEMS_THREAD_POOLS} is RTEMS specific. It
+determines the scheduler instance specific thread pools. The format for
hyphenate: "instance-specific"
Shouldn't this be "scheduler-instance-specific" ?
Maybe use "determines the thread pools for each scheduler instance".
+@env{GOMP_RTEMS_THREAD_POOLS} is a list of optional
+@code{[$]@@} configurations
+separated by @code{:} where:
+
+@itemize @bullet
+@item @code{} is the thread pool count for this scheduler
+instance.
+@item @code{$} is an optional priority for the worker threads of a
+thread pool according to @code{pthread_setschedparam}. In case a priority
+value is omitted, then a worker thread will inherit the priority of the OpenMP
+master thread that created it. The priority of the worker thread is not
+changed after creation, even if a new OpenMP master thread using the worker has
This statement "priority of the worker thread is not changed after
creation" probably is not accurate, in case of PIP/PCP or API calls to
change priority. It might be better to state that the priority is not
changed despite a change in the master thread?
The priority is implicitly the "real priority". I think it is clear
that protocols may do all sorts of stuff with the current priority of a
thread. Its not possible to change parameters of the worker threads by
API calls.
+a different priority.
+@item @code{@@} is the scheduler instance name according to the
+RTEMS application configuration.
+@end itemize
+
+In case no thread pool configuration is specified for a scheduler instance,
+then each OpenMP master thread of this scheduler instance will use its own
+dynamically allocated thread pool. To limit the worker thread count of the
+thread pools, each OpenMP master thread must call @code{omp_set_num_threads}.
+
+Lets suppose we have three scheduler instances @code{IO}, @code{WRK0}, and
+@code{WRK1} with @env{GOMP_RTEMS_THREAD_POOLS} set to
+@code{"1@@WRK0:3$4@@WRK1"}. Then there are no thread pool restrictions for
+scheduler instanc
Re: [PATCH] [RTEMS] Update RTEMS thread model
On 03/09/15 15:47, Martin Galvan wrote:
Hi Sebastian! Thanks for your answer. There are a couple of things I
still don't get :)
On Thu, Sep 3, 2015 at 2:48 AM, Sebastian Huber
wrote:
I updated the rtems-testing repository.
1. You have to adjust the VERSIONS file.
Is this file meant to help the scripts download the tool sources
automatically (like RSB does), or does it just point to local
directories where I'm supposed to place them? If it downloads them
automatically, should I replace 'cvs' by 'git' for e.g. gdb?
GDB is managed by git and for GCC I would use the git mirror.
2. You need the latest Git versions of Newlib, GCC and RTEMS.
So I should manually build a cross-gcc from the gcc trunk? I think
that's past 5.2, will RTEMS build ok with that?
Also, should I apply the patch you posted here:
https://gcc.gnu.org/ml/gcc-patches/2015-09/msg00019.html
?
No patches, just the latest versions, so GCC 6.0.
3. Use
./do_one -1 -r -g -v -M arm realview_pbx_a9_qemu
to run the GCC tests. Make sure the test runner "realview_pbx_a9_qemu"
works.
How can I test that? Should I build the realview_pbx_a9 BSP and run a
sample (e.g. ticker) on the latest Qemu?
The test runners are in "sim-scripts" make sure a "realview_pbx_a9_qemu
-i ticker.exe" produces the expected output.
4. Use something similar
cd gcc/b-arm-gcc/arm-rtems4.11/libstdc++-v3/testsuite
make check 'RUNTESTFLAGS= SIM=realview_pbx_a9_qemu
RTEMS_MAKEFILE_PATH=/scratch/git-rtems-testing/gcc/install-git/arm-rtems4.11/realview_pbx_a9_qemu
RTEMS_CONFIG_OBJ=/scratch/git-rtems-testing/gcc/b-arm-gcc/rtems_gcc_main.o
--target_board=rtems-arm-realview_pbx_a9_qemu{-march=armv7-a/-mthumb/-mfpu=neon/-mfloat-abi=hard}'
to run the libstdc++ tests.
Where does the /git-rtems-testing/gcc/install-git directory? I didn't
see an 'install-git' dir inside rtems-testing/gcc. Is it created after
doing make install on rtems-testing?
I don't remember. I set this up several months ago and now it just works.
--
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
