[PATCH] RTEMS: Add user-defined name to thread queues

[Sebastian Huber]

Add a user-defined name to the self-contained synchronization objects in
order to make system diagnostics, tracing and debugging more user
friendly.

Signed-off-by: Sebastian Huber 
---
 newlib/libc/sys/rtems/include/sys/lock.h | 66 +++-
 1 file changed, 65 insertions(+), 1 deletion(-)

diff --git a/newlib/libc/sys/rtems/include/sys/lock.h 
b/newlib/libc/sys/rtems/include/sys/lock.h
index c0549db..ec3415a 100644
--- a/newlib/libc/sys/rtems/include/sys/lock.h
+++ b/newlib/libc/sys/rtems/include/sys/lock.h
@@ -46,6 +46,7 @@ struct _Thread_queue_Queue {
struct _Ticket_lock_Control _Lock;
struct _Thread_queue_Heads *_heads;
struct _Thread_Control *_owner;
+   const char *_name;
 };
 
 struct _Mutex_Control {
@@ -72,18 +73,36 @@ struct _Futex_Control {
 
 #define _TICKET_LOCK_INITIALIZER { 0, 0 }
 
-#define _THREAD_QUEUE_INITIALIZER { _TICKET_LOCK_INITIALIZER, 0, 0 }
+#define _THREAD_QUEUE_INITIALIZER { _TICKET_LOCK_INITIALIZER, 0, 0, 0 }
+
+#define _THREAD_QUEUE_NAMED_INITIALIZER(_name) \
+{ _TICKET_LOCK_INITIALIZER, 0, 0, _name }
 
 #define _MUTEX_INITIALIZER { _THREAD_QUEUE_INITIALIZER }
 
+#define _MUTEX_NAMED_INITIALIZER(_name) \
+{ _THREAD_QUEUE_NAMED_INITIALIZER(_name) }
+
 #define _MUTEX_RECURSIVE_INITIALIZER { _MUTEX_INITIALIZER, 0 }
 
+#define _MUTEX_RECURSIVE_NAMED_INITIALIZER(_name) \
+{ _MUTEX_NAMED_INITIALIZER(_name), 0 }
+
 #define _CONDITION_INITIALIZER { _THREAD_QUEUE_INITIALIZER }
 
+#define _CONDITION_NAMED_INITIALIZER(_name) \
+{ _THREAD_QUEUE_NAMED_INITIALIZER(_name) }
+
 #define _SEMAPHORE_INITIALIZER(_count) { _THREAD_QUEUE_INITIALIZER, _count }
 
+#define _SEMAPHORE_NAMED_INITIALIZER(_name, _count) \
+{ _THREAD_QUEUE_NAMED_INITIALIZER(_name), _count }
+
 #define _FUTEX_INITIALIZER { _THREAD_QUEUE_INITIALIZER }
 
+#define _FUTEX_NAMED_INITIALIZER(_name) \
+{ _THREAD_QUEUE_NAMED_INITIALIZER(_name) }
+
 static __inline void
 _Mutex_Initialize(struct _Mutex_Control *_mutex)
 {
@@ -92,6 +111,14 @@ _Mutex_Initialize(struct _Mutex_Control *_mutex)
*_mutex = _init;
 }
 
+static __inline void
+_Mutex_Initialize_named(struct _Mutex_Control *_mutex, const char *_name)
+{
+   struct _Mutex_Control _init = _MUTEX_NAMED_INITIALIZER(_name);
+
+   *_mutex = _init;
+}
+
 void _Mutex_Acquire(struct _Mutex_Control *);
 
 int _Mutex_Acquire_timed(struct _Mutex_Control *, const struct timespec *);
@@ -115,6 +142,16 @@ _Mutex_recursive_Initialize(struct 
_Mutex_recursive_Control *_mutex)
*_mutex = _init;
 }
 
+static __inline void
+_Mutex_recursive_Initialize_named(struct _Mutex_recursive_Control *_mutex,
+const char *_name)
+{
+   struct _Mutex_recursive_Control _init =
+   _MUTEX_RECURSIVE_NAMED_INITIALIZER(_name);
+
+   *_mutex = _init;
+}
+
 void _Mutex_recursive_Acquire(struct _Mutex_recursive_Control *);
 
 int _Mutex_recursive_Acquire_timed(struct _Mutex_recursive_Control *,
@@ -139,6 +176,15 @@ _Condition_Initialize(struct _Condition_Control *_cond)
*_cond = _init;
 }
 
+static __inline void
+_Condition_Initialize_named(struct _Condition_Control *_cond,
+const char *_name)
+{
+   struct _Condition_Control _init = _CONDITION_NAMED_INITIALIZER(_name);
+
+   *_cond = _init;
+}
+
 void _Condition_Wait(struct _Condition_Control *, struct _Mutex_Control *);
 
 int _Condition_Wait_timed(struct _Condition_Control *,
@@ -170,6 +216,16 @@ _Semaphore_Initialize(struct _Semaphore_Control 
*_semaphore,
*_semaphore = _init;
 }
 
+static __inline void
+_Semaphore_Initialize_named(struct _Semaphore_Control *_semaphore,
+const char *_name, unsigned int _count)
+{
+   struct _Semaphore_Control _init =
+   _SEMAPHORE_NAMED_INITIALIZER(_name, _count);
+
+   *_semaphore = _init;
+}
+
 void _Semaphore_Wait(struct _Semaphore_Control *);
 
 void _Semaphore_Post(struct _Semaphore_Control *);
@@ -189,6 +245,14 @@ _Futex_Initialize(struct _Futex_Control *_futex)
*_futex = _init;
 }
 
+static __inline void
+_Futex_Initialize_named(struct _Futex_Control *_futex, const char *_name)
+{
+   struct _Futex_Control _init = _FUTEX_NAMED_INITIALIZER(_name);
+
+   *_futex = _init;
+}
+
 int _Futex_Wait(struct _Futex_Control *, int *, int);
 
 int _Futex_Wake(struct _Futex_Control *, int);
-- 
1.8.4.5

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: C11 Re: [PATCH 3/6] termios: Use C11 mutex for input/output

[Sebastian Huber]

On 20/12/16 23:37, Chris Johns wrote:

On 21/12/2016 08:20, Gedare Bloom wrote:

I haven't fully understood the distinction. I get that C11 are
individually (and collectively) smaller. I don't entirely get what is
their time-space tradeoff or when they are less desirable.


There are a few advantages to self-contained resources like mutexes 
for an API like C11 and POSIX.


1. All major POSIX implementations work this way. The libstdc++ code 
base assumes it, see 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78677. The standard does 
say POSIX create calls can return an error however it seems to be 
assumed this does not happen. A change in RTEMS brings us closer to 
the major implementations in this regard.


Also kernel synchronization objects in Linux, FreeBSD, etc. work like 
this. What you cannot do with self-contained objects is using them in a 
distributed system with distinct address spaces, e.g. a usage case RTEMS 
was initially designed for. Here you need one level of indirection to 
identify objects globally.




2. Performance. Sebastian's work with LibBSD, which is documented in 
the recent v3 SMP report highlighted the cost in the object look up in 
various hot parts of the kernel. This alone is a significant piece of 
data.


3. Deterministic resourcing. If you can link an application and it 
fits in memory the resource is allocated. There is no need to account 
and adjust a configuration parameter in another area of the system. 
This combines well with function section linking where we only have 
the referenced code in the target executable which means only the 
referenced resources are included.


4. Self-contained objects help dynamic loaded resource configuration. 
You do not know what can or could be loaded dynamically and how 
resources may be used or shared. A central base image configuration 
leads to possible conflicts in resource allocation. The unlimited 
patch back in the mid-90's was one solution to this problem, 
self-contains objects is another.


5. The objects reside in a table, e.g. they are suspect to false sharing 
of cache lines.


6. No global registry means no global bottleneck for dynamic systems 
that create/destroy synchronization objects in the hot path (e.g. OpenMP 
support via libgomp). See https://devel.rtems.org/ticket/2274, e.g. 
barrier bench on 24 processor T4240 783s vs. 5.7s (self-contained).


--
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: RTEMS SMP Status Report v3

[Sebastian Huber]

On 20/12/16 23:43, Chris Johns wrote:

On 21/12/2016 08:45, Gedare Bloom wrote:

On Tue, Dec 20, 2016 at 4:12 PM, Chris Johns  wrote:

On 19/12/2016 20:07, Sebastian Huber wrote:


Hello,

there is a third version of an RTEMS SMP Status Report available at:


http://microelectronics.esa.int/gr740/RTEMS-SMP-StatusReportEmbBrains-rev3-2016-12.pdf 





This is an excellent report.

Should some parts of this be added to the User Manual under an SMP 
section?



I would rather have a collection of "Technical Reports" that are
developer-community supported.



Yes of course, the report stands alone and I was not intending to say 
otherwise.


There are really good parts on how to write suitable SMP apps and also 
on the issues of moving code from a uni-processor to SMP system. I see 
these as being great user focused topics. It would be good if we can 
take what is there as base and reuse what we need, that is all I was 
asking. 


Some parts are already in the user manual. I work currently on user 
manual updates for SMP.


--
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] Changed hello world example to include my name

[Tanu Hari Dixit]

Hello Gedare,

I am looking forward to contributing to RTEMS!

Regards,
Tanu Hari Dixit


On Wed, Dec 21, 2016 at 2:35 AM, Gedare Bloom  wrote:
> Thank you, we look forward to your contributions!
>
> On Sat, Dec 17, 2016 at 7:38 PM, Tanu Hari Dixit  
> wrote:
>> Hello all,
>>
>> Please find the screenshot attached.
>>
>> Tanu Hari Dixit.
>>
>> On Sun, Dec 18, 2016 at 6:03 AM, tokencolour  wrote:
>>> This is something I tried after reading
>>> https://devel.rtems.org/wiki/GSoC/GettingStarted#ProveYouCanWorkOnRTEMS
>>> ---
>>>  testsuites/samples/hello/init.c | 6 +-
>>>  1 file changed, 5 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/testsuites/samples/hello/init.c 
>>> b/testsuites/samples/hello/init.c
>>> index a2d6c30..8fe9a6f 100644
>>> --- a/testsuites/samples/hello/init.c
>>> +++ b/testsuites/samples/hello/init.c
>>> @@ -31,7 +31,11 @@ rtems_task Init(
>>>  {
>>>rtems_print_printer_printf(_test_printer);
>>>rtems_test_begin();
>>> -  printf( "Hello World\n" );
>>> +  //printf( "Hello World\n" );
>>> +  printf( "\n\n*** GSOC HELLO WORLD TEST ***\n" );
>>> +  printf( "This is Tanu's Hello World\n" );
>>> +  printf( "Welcome to RTEMS and Google Summer of Code 2017\n" );
>>> +  printf( "*** END OF GSOC HELLO WORLD TEST ***\n" );
>>>rtems_test_end();
>>>exit( 0 );
>>>  }
>>> --
>>> 1.9.1
>>>
>>
>> ___
>> 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: RTEMS SMP Status Report v3

[Chris Johns]

On 21/12/2016 08:45, Gedare Bloom wrote:

On Tue, Dec 20, 2016 at 4:12 PM, Chris Johns  wrote:

On 19/12/2016 20:07, Sebastian Huber wrote:


Hello,

there is a third version of an RTEMS SMP Status Report available at:


http://microelectronics.esa.int/gr740/RTEMS-SMP-StatusReportEmbBrains-rev3-2016-12.pdf



This is an excellent report.

Should some parts of this be added to the User Manual under an SMP section?


I would rather have a collection of "Technical Reports" that are
developer-community supported.



Yes of course, the report stands alone and I was not intending to say 
otherwise.


There are really good parts on how to write suitable SMP apps and also 
on the issues of moving code from a uni-processor to SMP system. I see 
these as being great user focused topics. It would be good if we can 
take what is there as base and reuse what we need, that is all I was asking.


Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: C11 Re: [PATCH 3/6] termios: Use C11 mutex for input/output

[Chris Johns]

On 21/12/2016 08:20, Gedare Bloom wrote:

I haven't fully understood the distinction. I get that C11 are
individually (and collectively) smaller. I don't entirely get what is
their time-space tradeoff or when they are less desirable.


There are a few advantages to self-contained resources like mutexes for 
an API like C11 and POSIX.


1. All major POSIX implementations work this way. The libstdc++ code 
base assumes it, see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78677. 
The standard does say POSIX create calls can return an error however it 
seems to be assumed this does not happen. A change in RTEMS brings us 
closer to the major implementations in this regard.


2. Performance. Sebastian's work with LibBSD, which is documented in the 
recent v3 SMP report highlighted the cost in the object look up in 
various hot parts of the kernel. This alone is a significant piece of data.


3. Deterministic resourcing. If you can link an application and it fits 
in memory the resource is allocated. There is no need to account and 
adjust a configuration parameter in another area of the system. This 
combines well with function section linking where we only have the 
referenced code in the target executable which means only the referenced 
resources are included.


4. Self-contained objects help dynamic loaded resource configuration. 
You do not know what can or could be loaded dynamically and how 
resources may be used or shared. A central base image configuration 
leads to possible conflicts in resource allocation. The unlimited patch 
back in the mid-90's was one solution to this problem, self-contains 
objects is another.



I would
like to see a table that compares/contrasts these in a simple way to
evaluate. I will try to look closely at these different approaches in
a few weeks.


I hope the list above helps.

Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] Enhancement of the RMS manager for the overrun handling.

[Gedare Bloom]

On Fri, Dec 9, 2016 at 11:21 AM, Kuan-Hsun Chen  wrote:
> Three additional functions:
> RM_Postponed_num, RM_Renew_deadline, and RM_Release_postponedjob.
>
> Four refined functions:
> RM_Activate, RM_Block_while_expired, rtems_rate_monotonic_period, RM_Timeout.
>
> Rate_monotonic_Control contains one counter for counting the postponed jobs 
> and one for recording the recent deadline.
> ---
>  cpukit/rtems/include/rtems/rtems/ratemon.h |  42 ++--
>  cpukit/rtems/include/rtems/rtems/ratemonimpl.h |  25 +++--
>  cpukit/rtems/src/ratemonperiod.c   | 144 
> +
>  cpukit/rtems/src/ratemontimeout.c  |  13 ++-
>  4 files changed, 183 insertions(+), 41 deletions(-)
>
> diff --git a/cpukit/rtems/include/rtems/rtems/ratemon.h 
> b/cpukit/rtems/include/rtems/rtems/ratemon.h
> index 50b8478..71a99dc 100644
> --- a/cpukit/rtems/include/rtems/rtems/ratemon.h
> +++ b/cpukit/rtems/include/rtems/rtems/ratemon.h
> @@ -22,6 +22,7 @@
>
>  /* COPYRIGHT (c) 1989-2009, 2016.
>   * On-Line Applications Research Corporation (OAR).
> + * COPYRIGHT (c) 2016 Kuan-Hsun Chen, TU Dortmund University (TUDo).
>   *
>   * The license and distribution terms for this file may be
>   * found in the file LICENSE in this distribution or at
> @@ -194,11 +195,6 @@ typedef struct {
>/** This field is the object management portion of a Period instance. */
>Objects_Control Object;
>
> -  /**
> -   * @brief Protects the rate monotonic period state.
> -   */
> -  ISR_LOCK_MEMBER(Lock )
> -
Why are these removed?

>/** This is the timer used to provide the unblocking mechanism. */
>Watchdog_ControlTimer;
>
> @@ -206,12 +202,6 @@ typedef struct {
>rtems_rate_monotonic_period_states  state;
>
>/**
> -   * @brief A priority node for use by the scheduler job release and cancel
> -   * operations.
> -   */
> -  Priority_Node   Priority;
> -
> -  /**
Ditto.

> * This field contains the length of the next period to be
> * executed.
> */
> @@ -240,6 +230,19 @@ typedef struct {
> * This field contains the statistics maintained for the period.
> */
>Rate_monotonic_Statistics   Statistics;
> +
> +  /**
> +   * This field contains the number of postponed jobs. When the watchdog 
> timeout,
> +   * this variable will be increased immediately.
> +   */
> +  uint32_tpostponed_jobs;
> +
> +  /**
> +   *  This field contains the tick of the latest deadline decided by the 
> period
> +   *  watchdog.
> +   */
> +  uint64_tlatest_deadline;
> +
>  }   Rate_monotonic_Control;
>
>  /**
> @@ -386,6 +389,23 @@ void rtems_rate_monotonic_report_statistics_with_plugin(
>  void rtems_rate_monotonic_report_statistics( void );
>
>  /**
> + * @brief RTEMS Return the number of postponed jobs
remove "RTEMS".

> + *
> + * This is a helper function to return the number of postponed jobs by this
by -> in

> + * given period. This number is only increased by the corresponding watchdog,
Is it only in a given period, or is it postponed jobs generally, i.e.
you could miss multiple periods hence jobs in multiple periods would
be counted here?

> + * and is decreased by RMS manager with the postponed job releasing.
> + *
> + * @param[in] id is the period id
> + *
> + * @retval This helper function returns the number of postponed
> + * jobs with given period_id.
> + *
> + */
> +uint32_t rtems_rate_monotonic_Postponed_num(
See coding conventions for naming rules. this is better
'rtems_rate_monotonic_postponed_jobs(). Is this function needed in the
public-facing API?

> +  rtems_idperiod_id
> +);
> +
> +/**
>   * @brief RTEMS Rate Monotonic Period
>   *
>   * This routine implements the rtems_rate_monotonic_period directive. When
> diff --git a/cpukit/rtems/include/rtems/rtems/ratemonimpl.h 
> b/cpukit/rtems/include/rtems/rtems/ratemonimpl.h
> index b6b3ffd..6cdaaeb 100644
> --- a/cpukit/rtems/include/rtems/rtems/ratemonimpl.h
> +++ b/cpukit/rtems/include/rtems/rtems/ratemonimpl.h
> @@ -9,6 +9,7 @@
>  /*  COPYRIGHT (c) 1989-2008.
>   *  On-Line Applications Research Corporation (OAR).
>   *  Copyright (c) 2016 embedded brains GmbH.
> + *  COPYRIGHT (c) 2016 Kuan-Hsun Chen, TU Dortmund University (TUDo).
>   *
>   *  The license and distribution terms for this file may be
>   *  found in the file LICENSE in this distribution or at
> @@ -69,19 +70,19 @@ RTEMS_INLINE_ROUTINE Rate_monotonic_Control 
> *_Rate_monotonic_Allocate( void )
>  }
>
>  RTEMS_INLINE_ROUTINE void _Rate_monotonic_Acquire_critical(
> -  Rate_monotonic_Control *the_period,
> -  ISR_lock_Context   *lock_context
> +  Thread_Control   *the_thread,
> +  ISR_lock_Context *lock_context
>  )
>  {
> -  _ISR_lock_Acquire( _period->Lock, lock_context );
> +  _Thread_Wait_acquire_default_critical( the_thread, lock_context );
>  }
At 

Re: [PATCH] RMS scheduler overrun handling example

[Kuan Hsun Chen]

Hello Gedare,

Thanks, I will check the content of the patches again.

Best,
Kuan-Hsun

2016-12-20 22:57 GMT+01:00 Gedare Bloom :

> On Tue, Dec 20, 2016 at 4:53 PM, Kuan Hsun Chen  wrote:
> > Hi Gedare,
> >
> > I want to hold copyright. How should I do?
> >
> This depends on the policy of your employer/university. You should ask
> your supervisor/advisor about the issue, and look for relevant
> policies regarding copyright and/or open-source software.
>
> Then, you should just list yourself in the copyright line if you are
> allowed to hold the copyright, or you need to list your employer.
>
> > Best,
> > Kuan-Hsun
> >
> > 2016-12-20 22:51 GMT+01:00 Gedare Bloom :
> >>
> >> On Fri, Dec 9, 2016 at 11:40 AM, Kuan-Hsun Chen 
> wrote:
> >> > ---
> >> >  testsuites/sptests/Makefile.am |   2 +
> >> >  testsuites/sptests/configure.ac|   1 +
> >> >  testsuites/sptests/sprmsched01/Makefile.am |  21 +
> >> >  testsuites/sptests/sprmsched01/init.c  |  69
> 
> >> >  testsuites/sptests/sprmsched01/sprmsched01.doc |  33 
> >> >  testsuites/sptests/sprmsched01/sprmsched01.scn |  48 
> >> >  testsuites/sptests/sprmsched01/system.h|  64 +++
> >> >  testsuites/sptests/sprmsched01/tasks.c | 104
> >> > +
> >> >  8 files changed, 342 insertions(+)
> >> >  create mode 100644 testsuites/sptests/sprmsched01/Makefile.am
> >> >  create mode 100644 testsuites/sptests/sprmsched01/init.c
> >> >  create mode 100644 testsuites/sptests/sprmsched01/sprmsched01.doc
> >> >  create mode 100644 testsuites/sptests/sprmsched01/sprmsched01.scn
> >> >  create mode 100644 testsuites/sptests/sprmsched01/system.h
> >> >  create mode 100644 testsuites/sptests/sprmsched01/tasks.c
> >> >
> >> > diff --git a/testsuites/sptests/Makefile.am
> >> > b/testsuites/sptests/Makefile.am
> >> > index 54a4de7..4281abb 100644
> >> > --- a/testsuites/sptests/Makefile.am
> >> > +++ b/testsuites/sptests/Makefile.am
> >> > @@ -37,6 +37,7 @@ _SUBDIRS += spfatal29
> >> >  _SUBDIRS += spmutex01
> >> >  _SUBDIRS += spextensions01
> >> >  _SUBDIRS += spsysinit01
> >> > +_SUBDIRS += sprmsched01
> >> >  if HAS_SMP
> >> >  else
> >> >  _SUBDIRS += sp29
> >> > @@ -56,6 +57,7 @@ _SUBDIRS += sptimecounter03
> >> >  _SUBDIRS += spatomic01
> >> >  _SUBDIRS += spintrcritical22
> >> >  _SUBDIRS += spsem03
> >> > +_SUBDIRS += spresource01
> >> >  _SUBDIRS += spmrsp01
> >> >  _SUBDIRS += spscheduler01
> >> >  _SUBDIRS += spprofiling01
> >> > diff --git a/testsuites/sptests/configure.ac
> >> > b/testsuites/sptests/configure.ac
> >> > index 76d60e3..8a55aef 100644
> >> > --- a/testsuites/sptests/configure.ac
> >> > +++ b/testsuites/sptests/configure.ac
> >> > @@ -255,5 +255,6 @@ sptimer_err02/Makefile
> >> >  spcpuset01/Makefile
> >> >  spregion_err01/Makefile
> >> >  sppartition_err01/Makefile
> >> > +sprmsched01/Makefile
> >> >  ])
> >> >  AC_OUTPUT
> >> > diff --git a/testsuites/sptests/sprmsched01/Makefile.am
> >> > b/testsuites/sptests/sprmsched01/Makefile.am
> >> > new file mode 100644
> >> > index 000..f837b52
> >> > --- /dev/null
> >> > +++ b/testsuites/sptests/sprmsched01/Makefile.am
> >> > @@ -0,0 +1,21 @@
> >> > +
> >> > +rtems_tests_PROGRAMS = sprmsched01
> >> > +sprmsched01_SOURCES = init.c tasks.c system.h
> >> > +
> >> > +dist_rtems_tests_DATA = sprmsched01.scn
> >> > +dist_rtems_tests_DATA += sprmsched01.doc
> >> > +
> >> > +include $(RTEMS_ROOT)/make/custom/@RTEMS_BSP@.cfg
> >> > +include $(top_srcdir)/../automake/compile.am
> >> > +include $(top_srcdir)/../automake/leaf.am
> >> > +
> >> > +AM_CPPFLAGS += -I$(top_srcdir)/../support/include
> >> > +
> >> > +LINK_OBJS = $(sprmsched01_OBJECTS)
> >> > +LINK_LIBS = $(sprmsched01_LDLIBS)
> >> > +
> >> > +sprmsched01$(EXEEXT): $(sprmsched01_OBJECTS)
> >> > $(sprmsched01_DEPENDENCIES)
> >> > +   @rm -f sprmsched01$(EXEEXT)
> >> > +   $(make-exe)
> >> > +
> >> > +include $(top_srcdir)/../automake/local.am
> >> > diff --git a/testsuites/sptests/sprmsched01/init.c
> >> > b/testsuites/sptests/sprmsched01/init.c
> >> > new file mode 100644
> >> > index 000..7fd3e87
> >> > --- /dev/null
> >> > +++ b/testsuites/sptests/sprmsched01/init.c
> >> > @@ -0,0 +1,69 @@
> >> > +/**
> >> > + * @file sprmsched01/init.c
> >> > + *
> >> > + * @brief A init task body for sprmsched01 example.
> >> > + *
> >> > + */
> >> > +
> >> > +/*
> >> > + *  COPYRIGHT (c) 2016 Kuan-Hsun Chen, TU Dortmund University (TUDo).
> >> Please determine whether you hold copyright or your employer
> >>
> >> > + *
> >> > + *  The license and distribution terms for this file may be
> >> > + *  found in the file LICENSE in this distribution or at
> >> > + *  http://www.rtems.com/license/LICENSE.
> >> > + */
> >> > +
> >> > +#ifdef HAVE_CONFIG_H
> >> > +#include "config.h"
> >> > +#endif
> >> > +
> >> > +#define CONFIGURE_INIT
> >> > +#include "system.h"

Re: [PATCH] RMS scheduler overrun handling example

[Gedare Bloom]

On Tue, Dec 20, 2016 at 4:53 PM, Kuan Hsun Chen  wrote:
> Hi Gedare,
>
> I want to hold copyright. How should I do?
>
This depends on the policy of your employer/university. You should ask
your supervisor/advisor about the issue, and look for relevant
policies regarding copyright and/or open-source software.

Then, you should just list yourself in the copyright line if you are
allowed to hold the copyright, or you need to list your employer.

> Best,
> Kuan-Hsun
>
> 2016-12-20 22:51 GMT+01:00 Gedare Bloom :
>>
>> On Fri, Dec 9, 2016 at 11:40 AM, Kuan-Hsun Chen  wrote:
>> > ---
>> >  testsuites/sptests/Makefile.am |   2 +
>> >  testsuites/sptests/configure.ac|   1 +
>> >  testsuites/sptests/sprmsched01/Makefile.am |  21 +
>> >  testsuites/sptests/sprmsched01/init.c  |  69 
>> >  testsuites/sptests/sprmsched01/sprmsched01.doc |  33 
>> >  testsuites/sptests/sprmsched01/sprmsched01.scn |  48 
>> >  testsuites/sptests/sprmsched01/system.h|  64 +++
>> >  testsuites/sptests/sprmsched01/tasks.c | 104
>> > +
>> >  8 files changed, 342 insertions(+)
>> >  create mode 100644 testsuites/sptests/sprmsched01/Makefile.am
>> >  create mode 100644 testsuites/sptests/sprmsched01/init.c
>> >  create mode 100644 testsuites/sptests/sprmsched01/sprmsched01.doc
>> >  create mode 100644 testsuites/sptests/sprmsched01/sprmsched01.scn
>> >  create mode 100644 testsuites/sptests/sprmsched01/system.h
>> >  create mode 100644 testsuites/sptests/sprmsched01/tasks.c
>> >
>> > diff --git a/testsuites/sptests/Makefile.am
>> > b/testsuites/sptests/Makefile.am
>> > index 54a4de7..4281abb 100644
>> > --- a/testsuites/sptests/Makefile.am
>> > +++ b/testsuites/sptests/Makefile.am
>> > @@ -37,6 +37,7 @@ _SUBDIRS += spfatal29
>> >  _SUBDIRS += spmutex01
>> >  _SUBDIRS += spextensions01
>> >  _SUBDIRS += spsysinit01
>> > +_SUBDIRS += sprmsched01
>> >  if HAS_SMP
>> >  else
>> >  _SUBDIRS += sp29
>> > @@ -56,6 +57,7 @@ _SUBDIRS += sptimecounter03
>> >  _SUBDIRS += spatomic01
>> >  _SUBDIRS += spintrcritical22
>> >  _SUBDIRS += spsem03
>> > +_SUBDIRS += spresource01
>> >  _SUBDIRS += spmrsp01
>> >  _SUBDIRS += spscheduler01
>> >  _SUBDIRS += spprofiling01
>> > diff --git a/testsuites/sptests/configure.ac
>> > b/testsuites/sptests/configure.ac
>> > index 76d60e3..8a55aef 100644
>> > --- a/testsuites/sptests/configure.ac
>> > +++ b/testsuites/sptests/configure.ac
>> > @@ -255,5 +255,6 @@ sptimer_err02/Makefile
>> >  spcpuset01/Makefile
>> >  spregion_err01/Makefile
>> >  sppartition_err01/Makefile
>> > +sprmsched01/Makefile
>> >  ])
>> >  AC_OUTPUT
>> > diff --git a/testsuites/sptests/sprmsched01/Makefile.am
>> > b/testsuites/sptests/sprmsched01/Makefile.am
>> > new file mode 100644
>> > index 000..f837b52
>> > --- /dev/null
>> > +++ b/testsuites/sptests/sprmsched01/Makefile.am
>> > @@ -0,0 +1,21 @@
>> > +
>> > +rtems_tests_PROGRAMS = sprmsched01
>> > +sprmsched01_SOURCES = init.c tasks.c system.h
>> > +
>> > +dist_rtems_tests_DATA = sprmsched01.scn
>> > +dist_rtems_tests_DATA += sprmsched01.doc
>> > +
>> > +include $(RTEMS_ROOT)/make/custom/@RTEMS_BSP@.cfg
>> > +include $(top_srcdir)/../automake/compile.am
>> > +include $(top_srcdir)/../automake/leaf.am
>> > +
>> > +AM_CPPFLAGS += -I$(top_srcdir)/../support/include
>> > +
>> > +LINK_OBJS = $(sprmsched01_OBJECTS)
>> > +LINK_LIBS = $(sprmsched01_LDLIBS)
>> > +
>> > +sprmsched01$(EXEEXT): $(sprmsched01_OBJECTS)
>> > $(sprmsched01_DEPENDENCIES)
>> > +   @rm -f sprmsched01$(EXEEXT)
>> > +   $(make-exe)
>> > +
>> > +include $(top_srcdir)/../automake/local.am
>> > diff --git a/testsuites/sptests/sprmsched01/init.c
>> > b/testsuites/sptests/sprmsched01/init.c
>> > new file mode 100644
>> > index 000..7fd3e87
>> > --- /dev/null
>> > +++ b/testsuites/sptests/sprmsched01/init.c
>> > @@ -0,0 +1,69 @@
>> > +/**
>> > + * @file sprmsched01/init.c
>> > + *
>> > + * @brief A init task body for sprmsched01 example.
>> > + *
>> > + */
>> > +
>> > +/*
>> > + *  COPYRIGHT (c) 2016 Kuan-Hsun Chen, TU Dortmund University (TUDo).
>> Please determine whether you hold copyright or your employer
>>
>> > + *
>> > + *  The license and distribution terms for this file may be
>> > + *  found in the file LICENSE in this distribution or at
>> > + *  http://www.rtems.com/license/LICENSE.
>> > + */
>> > +
>> > +#ifdef HAVE_CONFIG_H
>> > +#include "config.h"
>> > +#endif
>> > +
>> > +#define CONFIGURE_INIT
>> > +#include "system.h"
>> > +
>> > +#include 
>> > +#include 
>> > +#include 
>> > +
>> > +const char rtems_test_name[] = "Rate Monotonic 01";
>> > +
>> > +/* Global variables */
>> > +rtems_id   Task_id[ 2 ]; /* array of task ids */
>> > +rtems_name Task_name[ 2 ];   /* array of task names */
>> > +uint32_t tick_per_second;/* time reference */
>> > +int testnumber = 11;  /* stop condition 

Re: [PATCH] RMS scheduler overrun handling example

[Gedare Bloom]

I'm not clear how to tell this test Passes vs Fails. a few more notes below.

On Fri, Dec 9, 2016 at 11:40 AM, Kuan-Hsun Chen  wrote:
> ---
>  testsuites/sptests/Makefile.am |   2 +
>  testsuites/sptests/configure.ac|   1 +
>  testsuites/sptests/sprmsched01/Makefile.am |  21 +
>  testsuites/sptests/sprmsched01/init.c  |  69 
>  testsuites/sptests/sprmsched01/sprmsched01.doc |  33 
>  testsuites/sptests/sprmsched01/sprmsched01.scn |  48 
>  testsuites/sptests/sprmsched01/system.h|  64 +++
>  testsuites/sptests/sprmsched01/tasks.c | 104 
> +
>  8 files changed, 342 insertions(+)
>  create mode 100644 testsuites/sptests/sprmsched01/Makefile.am
>  create mode 100644 testsuites/sptests/sprmsched01/init.c
>  create mode 100644 testsuites/sptests/sprmsched01/sprmsched01.doc
>  create mode 100644 testsuites/sptests/sprmsched01/sprmsched01.scn
>  create mode 100644 testsuites/sptests/sprmsched01/system.h
>  create mode 100644 testsuites/sptests/sprmsched01/tasks.c
>
> diff --git a/testsuites/sptests/Makefile.am b/testsuites/sptests/Makefile.am
> index 54a4de7..4281abb 100644
> --- a/testsuites/sptests/Makefile.am
> +++ b/testsuites/sptests/Makefile.am
> @@ -37,6 +37,7 @@ _SUBDIRS += spfatal29
>  _SUBDIRS += spmutex01
>  _SUBDIRS += spextensions01
>  _SUBDIRS += spsysinit01
> +_SUBDIRS += sprmsched01
>  if HAS_SMP
>  else
>  _SUBDIRS += sp29
> @@ -56,6 +57,7 @@ _SUBDIRS += sptimecounter03
>  _SUBDIRS += spatomic01
>  _SUBDIRS += spintrcritical22
>  _SUBDIRS += spsem03
> +_SUBDIRS += spresource01
>  _SUBDIRS += spmrsp01
>  _SUBDIRS += spscheduler01
>  _SUBDIRS += spprofiling01
> diff --git a/testsuites/sptests/configure.ac b/testsuites/sptests/configure.ac
> index 76d60e3..8a55aef 100644
> --- a/testsuites/sptests/configure.ac
> +++ b/testsuites/sptests/configure.ac
> @@ -255,5 +255,6 @@ sptimer_err02/Makefile
>  spcpuset01/Makefile
>  spregion_err01/Makefile
>  sppartition_err01/Makefile
> +sprmsched01/Makefile
>  ])
>  AC_OUTPUT
> diff --git a/testsuites/sptests/sprmsched01/Makefile.am 
> b/testsuites/sptests/sprmsched01/Makefile.am
> new file mode 100644
> index 000..f837b52
> --- /dev/null
> +++ b/testsuites/sptests/sprmsched01/Makefile.am
> @@ -0,0 +1,21 @@
> +
> +rtems_tests_PROGRAMS = sprmsched01
> +sprmsched01_SOURCES = init.c tasks.c system.h
> +
> +dist_rtems_tests_DATA = sprmsched01.scn
> +dist_rtems_tests_DATA += sprmsched01.doc
> +
> +include $(RTEMS_ROOT)/make/custom/@RTEMS_BSP@.cfg
> +include $(top_srcdir)/../automake/compile.am
> +include $(top_srcdir)/../automake/leaf.am
> +
> +AM_CPPFLAGS += -I$(top_srcdir)/../support/include
> +
> +LINK_OBJS = $(sprmsched01_OBJECTS)
> +LINK_LIBS = $(sprmsched01_LDLIBS)
> +
> +sprmsched01$(EXEEXT): $(sprmsched01_OBJECTS) $(sprmsched01_DEPENDENCIES)
> +   @rm -f sprmsched01$(EXEEXT)
> +   $(make-exe)
> +
> +include $(top_srcdir)/../automake/local.am
> diff --git a/testsuites/sptests/sprmsched01/init.c 
> b/testsuites/sptests/sprmsched01/init.c
> new file mode 100644
> index 000..7fd3e87
> --- /dev/null
> +++ b/testsuites/sptests/sprmsched01/init.c
> @@ -0,0 +1,69 @@
> +/**
> + * @file sprmsched01/init.c
> + *
> + * @brief A init task body for sprmsched01 example.
> + *
> + */
> +
> +/*
> + *  COPYRIGHT (c) 2016 Kuan-Hsun Chen, TU Dortmund University (TUDo).
> + *
> + *  The license and distribution terms for this file may be
> + *  found in the file LICENSE in this distribution or at
> + *  http://www.rtems.com/license/LICENSE.
> + */
> +
> +#ifdef HAVE_CONFIG_H
> +#include "config.h"
> +#endif
> +
> +#define CONFIGURE_INIT
> +#include "system.h"
> +
> +#include 
> +#include 
> +#include 
> +
> +const char rtems_test_name[] = "Rate Monotonic 01";
> +
There exist other tests of RM. I prefer this should indicate it is an
overrun test.

> +/* Global variables */
> +rtems_id   Task_id[ 2 ]; /* array of task ids */
> +rtems_name Task_name[ 2 ];   /* array of task names */
> +uint32_t tick_per_second;/* time reference */
> +int testnumber = 11;  /* stop condition */
> +
> +rtems_task_priority Prio[3] = {0, 2, 5};
> +
> +rtems_task Init(
> +   rtems_task_argument argument
> +)
> +{
> +  rtems_status_code status;
> +  TEST_BEGIN();
> +
> +
> +  tick_per_second = rtems_clock_get_ticks_per_second();
> +  printf("\nTicks per second in your system: %" PRIu32 "\n", 
> tick_per_second);
> +
> +  Task_name[ 1 ] = rtems_build_name( 'T', 'A', '1', ' ' );
> +  Task_name[ 2 ] = rtems_build_name( 'T', 'A', '2', ' ' );
> +
> +  /* Create two tasks */
> +  for ( int index = 1; index <= 2; index++){
Put all var decls at start of function scope. add consistent
whitespace. see
https://devel.rtems.org/wiki/Developer/Coding/Conventions

> +status = rtems_task_create(
> +  Task_name[ index ], Prio[index], RTEMS_MINIMUM_STACK_SIZE, 
> RTEMS_DEFAULT_MODES,
> +  

Re: [PATCH 1/7] Adding pipe support

[Chris Johns]

On 21/12/2016 01:53, Kirspel, Kevin wrote:


Maybe I misinterpreted the instructions in libbsd.txt, but it states not to 
commit changes from libbsd_waf.py so they were not in the patch files.



The generated file is held in git. If libbsd.txt is not clear please 
feel free to make it clearer.


Thanks
Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] RMS scheduler overrun handling example

[Kuan Hsun Chen]

Hi Gedare,

I want to hold copyright. How should I do?

Best,
Kuan-Hsun

2016-12-20 22:51 GMT+01:00 Gedare Bloom :

> On Fri, Dec 9, 2016 at 11:40 AM, Kuan-Hsun Chen  wrote:
> > ---
> >  testsuites/sptests/Makefile.am |   2 +
> >  testsuites/sptests/configure.ac|   1 +
> >  testsuites/sptests/sprmsched01/Makefile.am |  21 +
> >  testsuites/sptests/sprmsched01/init.c  |  69 
> >  testsuites/sptests/sprmsched01/sprmsched01.doc |  33 
> >  testsuites/sptests/sprmsched01/sprmsched01.scn |  48 
> >  testsuites/sptests/sprmsched01/system.h|  64 +++
> >  testsuites/sptests/sprmsched01/tasks.c | 104
> +
> >  8 files changed, 342 insertions(+)
> >  create mode 100644 testsuites/sptests/sprmsched01/Makefile.am
> >  create mode 100644 testsuites/sptests/sprmsched01/init.c
> >  create mode 100644 testsuites/sptests/sprmsched01/sprmsched01.doc
> >  create mode 100644 testsuites/sptests/sprmsched01/sprmsched01.scn
> >  create mode 100644 testsuites/sptests/sprmsched01/system.h
> >  create mode 100644 testsuites/sptests/sprmsched01/tasks.c
> >
> > diff --git a/testsuites/sptests/Makefile.am
> b/testsuites/sptests/Makefile.am
> > index 54a4de7..4281abb 100644
> > --- a/testsuites/sptests/Makefile.am
> > +++ b/testsuites/sptests/Makefile.am
> > @@ -37,6 +37,7 @@ _SUBDIRS += spfatal29
> >  _SUBDIRS += spmutex01
> >  _SUBDIRS += spextensions01
> >  _SUBDIRS += spsysinit01
> > +_SUBDIRS += sprmsched01
> >  if HAS_SMP
> >  else
> >  _SUBDIRS += sp29
> > @@ -56,6 +57,7 @@ _SUBDIRS += sptimecounter03
> >  _SUBDIRS += spatomic01
> >  _SUBDIRS += spintrcritical22
> >  _SUBDIRS += spsem03
> > +_SUBDIRS += spresource01
> >  _SUBDIRS += spmrsp01
> >  _SUBDIRS += spscheduler01
> >  _SUBDIRS += spprofiling01
> > diff --git a/testsuites/sptests/configure.ac b/testsuites/sptests/
> configure.ac
> > index 76d60e3..8a55aef 100644
> > --- a/testsuites/sptests/configure.ac
> > +++ b/testsuites/sptests/configure.ac
> > @@ -255,5 +255,6 @@ sptimer_err02/Makefile
> >  spcpuset01/Makefile
> >  spregion_err01/Makefile
> >  sppartition_err01/Makefile
> > +sprmsched01/Makefile
> >  ])
> >  AC_OUTPUT
> > diff --git a/testsuites/sptests/sprmsched01/Makefile.am
> b/testsuites/sptests/sprmsched01/Makefile.am
> > new file mode 100644
> > index 000..f837b52
> > --- /dev/null
> > +++ b/testsuites/sptests/sprmsched01/Makefile.am
> > @@ -0,0 +1,21 @@
> > +
> > +rtems_tests_PROGRAMS = sprmsched01
> > +sprmsched01_SOURCES = init.c tasks.c system.h
> > +
> > +dist_rtems_tests_DATA = sprmsched01.scn
> > +dist_rtems_tests_DATA += sprmsched01.doc
> > +
> > +include $(RTEMS_ROOT)/make/custom/@RTEMS_BSP@.cfg
> > +include $(top_srcdir)/../automake/compile.am
> > +include $(top_srcdir)/../automake/leaf.am
> > +
> > +AM_CPPFLAGS += -I$(top_srcdir)/../support/include
> > +
> > +LINK_OBJS = $(sprmsched01_OBJECTS)
> > +LINK_LIBS = $(sprmsched01_LDLIBS)
> > +
> > +sprmsched01$(EXEEXT): $(sprmsched01_OBJECTS) $(sprmsched01_DEPENDENCIES)
> > +   @rm -f sprmsched01$(EXEEXT)
> > +   $(make-exe)
> > +
> > +include $(top_srcdir)/../automake/local.am
> > diff --git a/testsuites/sptests/sprmsched01/init.c b/testsuites/sptests/
> sprmsched01/init.c
> > new file mode 100644
> > index 000..7fd3e87
> > --- /dev/null
> > +++ b/testsuites/sptests/sprmsched01/init.c
> > @@ -0,0 +1,69 @@
> > +/**
> > + * @file sprmsched01/init.c
> > + *
> > + * @brief A init task body for sprmsched01 example.
> > + *
> > + */
> > +
> > +/*
> > + *  COPYRIGHT (c) 2016 Kuan-Hsun Chen, TU Dortmund University (TUDo).
> Please determine whether you hold copyright or your employer
>
> > + *
> > + *  The license and distribution terms for this file may be
> > + *  found in the file LICENSE in this distribution or at
> > + *  http://www.rtems.com/license/LICENSE.
> > + */
> > +
> > +#ifdef HAVE_CONFIG_H
> > +#include "config.h"
> > +#endif
> > +
> > +#define CONFIGURE_INIT
> > +#include "system.h"
> > +
> > +#include 
> > +#include 
> > +#include 
> > +
> > +const char rtems_test_name[] = "Rate Monotonic 01";
> > +
> > +/* Global variables */
> > +rtems_id   Task_id[ 2 ]; /* array of task ids */
> > +rtems_name Task_name[ 2 ];   /* array of task names */
> > +uint32_t tick_per_second;/* time reference */
> > +int testnumber = 11;  /* stop condition */
> > +
> > +rtems_task_priority Prio[3] = {0, 2, 5};
> > +
> > +rtems_task Init(
> > +   rtems_task_argument argument
> > +)
> > +{
> > +  rtems_status_code status;
> > +  TEST_BEGIN();
> > +
> > +
> > +  tick_per_second = rtems_clock_get_ticks_per_second();
> > +  printf("\nTicks per second in your system: %" PRIu32 "\n",
> tick_per_second);
> > +
> > +  Task_name[ 1 ] = rtems_build_name( 'T', 'A', '1', ' ' );
> > +  Task_name[ 2 ] = rtems_build_name( 'T', 'A', '2', ' ' );
> > +
> > +  /* Create two tasks */
> > +  for ( int index = 1; 

Re: [PATCH] RMS scheduler overrun handling example

[Gedare Bloom]

On Fri, Dec 9, 2016 at 11:40 AM, Kuan-Hsun Chen  wrote:
> ---
>  testsuites/sptests/Makefile.am |   2 +
>  testsuites/sptests/configure.ac|   1 +
>  testsuites/sptests/sprmsched01/Makefile.am |  21 +
>  testsuites/sptests/sprmsched01/init.c  |  69 
>  testsuites/sptests/sprmsched01/sprmsched01.doc |  33 
>  testsuites/sptests/sprmsched01/sprmsched01.scn |  48 
>  testsuites/sptests/sprmsched01/system.h|  64 +++
>  testsuites/sptests/sprmsched01/tasks.c | 104 
> +
>  8 files changed, 342 insertions(+)
>  create mode 100644 testsuites/sptests/sprmsched01/Makefile.am
>  create mode 100644 testsuites/sptests/sprmsched01/init.c
>  create mode 100644 testsuites/sptests/sprmsched01/sprmsched01.doc
>  create mode 100644 testsuites/sptests/sprmsched01/sprmsched01.scn
>  create mode 100644 testsuites/sptests/sprmsched01/system.h
>  create mode 100644 testsuites/sptests/sprmsched01/tasks.c
>
> diff --git a/testsuites/sptests/Makefile.am b/testsuites/sptests/Makefile.am
> index 54a4de7..4281abb 100644
> --- a/testsuites/sptests/Makefile.am
> +++ b/testsuites/sptests/Makefile.am
> @@ -37,6 +37,7 @@ _SUBDIRS += spfatal29
>  _SUBDIRS += spmutex01
>  _SUBDIRS += spextensions01
>  _SUBDIRS += spsysinit01
> +_SUBDIRS += sprmsched01
>  if HAS_SMP
>  else
>  _SUBDIRS += sp29
> @@ -56,6 +57,7 @@ _SUBDIRS += sptimecounter03
>  _SUBDIRS += spatomic01
>  _SUBDIRS += spintrcritical22
>  _SUBDIRS += spsem03
> +_SUBDIRS += spresource01
>  _SUBDIRS += spmrsp01
>  _SUBDIRS += spscheduler01
>  _SUBDIRS += spprofiling01
> diff --git a/testsuites/sptests/configure.ac b/testsuites/sptests/configure.ac
> index 76d60e3..8a55aef 100644
> --- a/testsuites/sptests/configure.ac
> +++ b/testsuites/sptests/configure.ac
> @@ -255,5 +255,6 @@ sptimer_err02/Makefile
>  spcpuset01/Makefile
>  spregion_err01/Makefile
>  sppartition_err01/Makefile
> +sprmsched01/Makefile
>  ])
>  AC_OUTPUT
> diff --git a/testsuites/sptests/sprmsched01/Makefile.am 
> b/testsuites/sptests/sprmsched01/Makefile.am
> new file mode 100644
> index 000..f837b52
> --- /dev/null
> +++ b/testsuites/sptests/sprmsched01/Makefile.am
> @@ -0,0 +1,21 @@
> +
> +rtems_tests_PROGRAMS = sprmsched01
> +sprmsched01_SOURCES = init.c tasks.c system.h
> +
> +dist_rtems_tests_DATA = sprmsched01.scn
> +dist_rtems_tests_DATA += sprmsched01.doc
> +
> +include $(RTEMS_ROOT)/make/custom/@RTEMS_BSP@.cfg
> +include $(top_srcdir)/../automake/compile.am
> +include $(top_srcdir)/../automake/leaf.am
> +
> +AM_CPPFLAGS += -I$(top_srcdir)/../support/include
> +
> +LINK_OBJS = $(sprmsched01_OBJECTS)
> +LINK_LIBS = $(sprmsched01_LDLIBS)
> +
> +sprmsched01$(EXEEXT): $(sprmsched01_OBJECTS) $(sprmsched01_DEPENDENCIES)
> +   @rm -f sprmsched01$(EXEEXT)
> +   $(make-exe)
> +
> +include $(top_srcdir)/../automake/local.am
> diff --git a/testsuites/sptests/sprmsched01/init.c 
> b/testsuites/sptests/sprmsched01/init.c
> new file mode 100644
> index 000..7fd3e87
> --- /dev/null
> +++ b/testsuites/sptests/sprmsched01/init.c
> @@ -0,0 +1,69 @@
> +/**
> + * @file sprmsched01/init.c
> + *
> + * @brief A init task body for sprmsched01 example.
> + *
> + */
> +
> +/*
> + *  COPYRIGHT (c) 2016 Kuan-Hsun Chen, TU Dortmund University (TUDo).
Please determine whether you hold copyright or your employer

> + *
> + *  The license and distribution terms for this file may be
> + *  found in the file LICENSE in this distribution or at
> + *  http://www.rtems.com/license/LICENSE.
> + */
> +
> +#ifdef HAVE_CONFIG_H
> +#include "config.h"
> +#endif
> +
> +#define CONFIGURE_INIT
> +#include "system.h"
> +
> +#include 
> +#include 
> +#include 
> +
> +const char rtems_test_name[] = "Rate Monotonic 01";
> +
> +/* Global variables */
> +rtems_id   Task_id[ 2 ]; /* array of task ids */
> +rtems_name Task_name[ 2 ];   /* array of task names */
> +uint32_t tick_per_second;/* time reference */
> +int testnumber = 11;  /* stop condition */
> +
> +rtems_task_priority Prio[3] = {0, 2, 5};
> +
> +rtems_task Init(
> +   rtems_task_argument argument
> +)
> +{
> +  rtems_status_code status;
> +  TEST_BEGIN();
> +
> +
> +  tick_per_second = rtems_clock_get_ticks_per_second();
> +  printf("\nTicks per second in your system: %" PRIu32 "\n", 
> tick_per_second);
> +
> +  Task_name[ 1 ] = rtems_build_name( 'T', 'A', '1', ' ' );
> +  Task_name[ 2 ] = rtems_build_name( 'T', 'A', '2', ' ' );
> +
> +  /* Create two tasks */
> +  for ( int index = 1; index <= 2; index++){
> +status = rtems_task_create(
> +  Task_name[ index ], Prio[index], RTEMS_MINIMUM_STACK_SIZE, 
> RTEMS_DEFAULT_MODES,
> +  RTEMS_DEFAULT_ATTRIBUTES, _id[ index ]
> +);
> +directive_failed( status, "rtems_task_create loop");
> +  }
> +
> +
> +  /* After creating the periods for tasks, start to run them sequencially. */
> +  for ( int index = 1; index <= 2; index++){

Re: [PATCH] Update RMS documentation

[Gedare Bloom]

On Fri, Dec 9, 2016 at 11:22 AM, Kuan-Hsun Chen  wrote:
> ---
>  c-user/rate_monotonic_manager.rst | 30 +-
>  1 file changed, 17 insertions(+), 13 deletions(-)
>
> diff --git a/c-user/rate_monotonic_manager.rst 
> b/c-user/rate_monotonic_manager.rst
> index 8ad74e5..292e4bc 100644
> --- a/c-user/rate_monotonic_manager.rst
> +++ b/c-user/rate_monotonic_manager.rst
> @@ -132,7 +132,7 @@ milliseconds every 100 (10 percent of the CPU).  As a 
> general rule of thumb,
>  the higher frequency at which a task executes, the more important it is to
>  optimize that task.
>
> -Rate Monotonic Manager Definitions
> +Periodicity Definitions
>  --
>  .. index:: periodic task, definition
>
> @@ -170,7 +170,7 @@ Rate Monotonic Scheduling Algorithm
>  .. index:: RMS Algorithm, definition
>
>  The Rate Monotonic Scheduling Algorithm (RMS) is important to real-time 
> systems
> -designers because it allows one to guarantee that a set of tasks is
> +designers because it allows one to sufficiently guarantee that a set of 
> tasks is
>  schedulable.  A set of tasks is said to be schedulable if all of the tasks 
> can
>  meet their deadlines.  RMS provides a set of rules which can be used to 
> perform
>  a guaranteed schedulability analysis for a task set.  This analysis 
> determines
> @@ -179,11 +179,11 @@ the predictability of the system's behavior.  It has 
> been proven that:
>
>  .. sidebar:: *RMS*
>
> -  RMS is an optimal static priority algorithm for scheduling independent,
> +  RMS is an optimal fixed-priority algorithm for scheduling independent,
>preemptible, periodic tasks on a single processor.
>
>  RMS is optimal in the sense that if a set of tasks can be scheduled by any
> -static priority algorithm, then RMS will be able to schedule that task set.
> +fixed-priority algorithm, then RMS will be able to schedule that task set.
>  RMS bases it schedulability analysis on the processor utilization level below
>  which all deadlines can be met.
>
> @@ -230,7 +230,7 @@ Schedulability Analysis
>
>  .. index:: RMS schedulability analysis
>
> -RMS allows application designers to ensure that tasks can meet all deadlines,
> +RMS allows application designers to ensure that tasks can meet all deadlines 
> under fixed-priority assignment,
>  even under transient overload, without knowing exactly when any given task 
> will
>  execute by applying proven schedulability analysis rules.
>
> @@ -468,9 +468,10 @@ monotonic period results in one of the following 
> scenarios:
>immediately.
>
>  - If the rate monotonic period has expired before the task invokes the
> -  ``rtems_rate_monotonic_period`` directive, the period will be initiated 
> with
> -  a length of period ticks and the calling task returns immediately with a
> -  timeout error status.
> +  ``rtems_rate_monotonic_period`` directive, the postponed job will be 
> released
> +  until there is no more postponed jobs. The calling task returns immediately
> +  with a timeout error status. In the watchdog routine, the period will still
> +  be updated periodically and track the number of the postponed periods.
>
>  Obtaining the Status of a Period
>  
> @@ -560,8 +561,8 @@ Subsequent invocations of the 
> ``rtems_rate_monotonic_period`` directive will
>  result in the task blocking for the remainder of the 100 tick period.  If, 
> for
>  any reason, the body of the loop takes more than 100 ticks to execute, the
>  ``rtems_rate_monotonic_period`` directive will return the ``RTEMS_TIMEOUT``
> -status.  If the above task misses its deadline, it will delete the rate
> -monotonic period and itself.
> +status and the postponed job will be released.  If the above task misses
> +its deadline, it will delete the rate monotonic period and itself.
>
>  Task with Multiple Periods
>  --
> @@ -629,8 +630,8 @@ will not block.
>
>  If, for any reason, the task misses any deadline, the
>  ``rtems_rate_monotonic_period`` directive will return the ``RTEMS_TIMEOUT``
> -directive status.  If the above task misses its deadline, it will delete the
> -rate monotonic periods and itself.
> +directive status and the postponed job will be released. If the above task 
> misses
> +its deadline, it will delete the rate monotonic periods and itself.
>
>  Directives
>  ==
> @@ -839,7 +840,10 @@ DESCRIPTION:
>  period ticks.  If id is running, then the calling task will block for the
>  remainder of the period before reinitiating the period with the specified
>  period.  If id was not running (either expired or never initiated), the
> -period is immediately initiated and the directive returns immediately.
> +period is immediately initiated and the directive returns immediately.
> +   If id has expired its period, the postponed job will be released 
> immediately
> +   and the following calls of this directive will keep release those 

Re: RTEMS SMP Status Report v3

[Gedare Bloom]

On Tue, Dec 20, 2016 at 4:12 PM, Chris Johns  wrote:
> On 19/12/2016 20:07, Sebastian Huber wrote:
>>
>> Hello,
>>
>> there is a third version of an RTEMS SMP Status Report available at:
>>
>>
>> http://microelectronics.esa.int/gr740/RTEMS-SMP-StatusReportEmbBrains-rev3-2016-12.pdf
>>
>
> This is an excellent report.
>
> Should some parts of this be added to the User Manual under an SMP section?
>
I would rather have a collection of "Technical Reports" that are
developer-community supported.

> Chris
>
> ___
> 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: C11 Re: [PATCH 3/6] termios: Use C11 mutex for input/output

[Gedare Bloom]

On Fri, Dec 16, 2016 at 11:26 AM, Sebastian Huber
 wrote:
>
>
> On 15/12/16 23:34, Chris Johns wrote:
>>
>> On 15/12/2016 18:02, Sebastian Huber wrote:
>>>
>>> On 14/12/16 22:15, Chris Johns wrote:

 On 15/12/2016 00:39, Sebastian Huber wrote:
>
> [...]

 Would the "tiny" footprint be smaller if all internal services
 including compiler thread support are made C11? Could this actually be
 done? Parts of POSIX has been creeping in over time so the position is
 a little confused at the moment. I am not sure about a bits and pieces
 approach, maybe a full switch is made.
>>>
>>>
>>> Yes, the footprint would be smaller. If we provide self-contained
>>> threads, then the footprint would be much smaller, e.g. no object
>>> administration, no heap.
>>
>>
>> Great. This is a powerful reason to look at moving in this direction and
>> removing the remaining POSIX usage in libstdthreads.
>>
>> A brief audit of rtems.git shows the change is possible with less than 30
>> Classic task creates and a similar number of semaphore creates so a full
>> change look reachable which is nice.
>>
>> Should we look at moving all internal services to C11 and standardise it?
>> I think there is value in doing this. It can be a post 4.12 branch activity.
>
>
> In contrast to the C11 mutexes, I don't see a real value in moving from
> Classic API tasks to C11 threads. The Classic API you have more control over
> task attributes, modes, priority, stack size, etc.
>
> I created two tickets:
>
> https://devel.rtems.org/ticket/2842
> https://devel.rtems.org/ticket/2843
>
> Joel, Gedare, what is your opinion with respect to C11 mutexes?
>
I haven't fully understood the distinction. I get that C11 are
individually (and collectively) smaller. I don't entirely get what is
their time-space tradeoff or when they are less desirable. I would
like to see a table that compares/contrasts these in a simple way to
evaluate. I will try to look closely at these different approaches in
a few weeks.

>
> --
> 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: RTEMS SMP Status Report v3

[Chris Johns]

On 19/12/2016 20:07, Sebastian Huber wrote:

Hello,

there is a third version of an RTEMS SMP Status Report available at:

http://microelectronics.esa.int/gr740/RTEMS-SMP-StatusReportEmbBrains-rev3-2016-12.pdf



This is an excellent report.

Should some parts of this be added to the User Manual under an SMP section?

Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] Changed hello world example to include my name

[Gedare Bloom]

Thank you, we look forward to your contributions!

On Sat, Dec 17, 2016 at 7:38 PM, Tanu Hari Dixit  wrote:
> Hello all,
>
> Please find the screenshot attached.
>
> Tanu Hari Dixit.
>
> On Sun, Dec 18, 2016 at 6:03 AM, tokencolour  wrote:
>> This is something I tried after reading
>> https://devel.rtems.org/wiki/GSoC/GettingStarted#ProveYouCanWorkOnRTEMS
>> ---
>>  testsuites/samples/hello/init.c | 6 +-
>>  1 file changed, 5 insertions(+), 1 deletion(-)
>>
>> diff --git a/testsuites/samples/hello/init.c 
>> b/testsuites/samples/hello/init.c
>> index a2d6c30..8fe9a6f 100644
>> --- a/testsuites/samples/hello/init.c
>> +++ b/testsuites/samples/hello/init.c
>> @@ -31,7 +31,11 @@ rtems_task Init(
>>  {
>>rtems_print_printer_printf(_test_printer);
>>rtems_test_begin();
>> -  printf( "Hello World\n" );
>> +  //printf( "Hello World\n" );
>> +  printf( "\n\n*** GSOC HELLO WORLD TEST ***\n" );
>> +  printf( "This is Tanu's Hello World\n" );
>> +  printf( "Welcome to RTEMS and Google Summer of Code 2017\n" );
>> +  printf( "*** END OF GSOC HELLO WORLD TEST ***\n" );
>>rtems_test_end();
>>exit( 0 );
>>  }
>> --
>> 1.9.1
>>
>
> ___
> 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: POSIX compliance development

[Gedare Bloom]

Option #1 writing a script is better. We occasionally add
implementations for POSIX features as needed for various compliance
test requirements or application portability.

On Thu, Dec 15, 2016 at 9:29 AM, Saeed Ehteshamifar
 wrote:
> Hello,
>
> For Slingshot, an RTEMS-targeted fault-injection tool for the POSIX API, I
> need to remove the tests that correspond to unimplemented/unimplementable
> POSIX functions/constants/etc. I can either
> 1. write a script that searches for "Unimplemented" and "Unimplementable" in
> the doc's source, and removes the corresponding function's test cases every
> time after generating test cases or,
> 2. manually delete all unimplemented/unimplementable from the Slingshot core
> so that they aren't generated at all.
>
> Now the question is: Apart from unimplementable functions, is there any
> direction to implement unimplemented parts beyond the current situation?
> Cause in that case, I think writing a script is a better option.
>
> Best Regards,
> Saeed
>
> ___
> 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 1/1] getting started for gsoc

[Gedare Bloom]

Thank you. We look forward to your contributions to RTEMS!

On Thu, Dec 15, 2016 at 9:06 AM, Sagar Gupta
 wrote:
> From: sgmonusg 
>
> ---
>  testsuites/samples/hello/init.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/testsuites/samples/hello/init.c b/testsuites/samples/hello/init.c
> index a2d6c30..2aca030 100644
> --- a/testsuites/samples/hello/init.c
> +++ b/testsuites/samples/hello/init.c
> @@ -31,7 +31,7 @@ rtems_task Init(
>  {
>rtems_print_printer_printf(_test_printer);
>rtems_test_begin();
> -  printf( "Hello World\n" );
> +  printf( "Hello sagar\n" );
>rtems_test_end();
>exit( 0 );
>  }
> --
> 1.9.1
>
> ___
> 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 1/7] Adding pipe support

[Kirspel, Kevin]

I finally got back to this.  I complied the Xilinx BSP, compiled the latest 
LIBBSD with the patch, and installed QEMU.  I got the output below.  After you 
applied the patch, did you run "./freebsd-to-rtems.py -R" and " 
./freebsd-to-rtems.py".  If not, then the test will use the RTEMS pipe 
implementation instead of LIBBSD.  This is because the libbsd_waf.py file is 
not updated until after the " ./freebsd-to-rtems.py" script.  Maybe I 
misinterpreted the instructions in libbsd.txt, but it states not to commit 
changes from libbsd_waf.py so they were not in the patch files.

qemu-system-arm -no-reboot -serial null -serial mon:stdio -net none -nographic 
-M xilinx-zynq-a9 -m 256M -kernel 
build/arm-rtems4.12-xilinx_zynq_a9_qemu/selectpollkqueue01.exe
Warning: nic cadence_gem.0 has no peer
Warning: nic cadence_gem.1 has no peer
*** LIBBSD SELECT AND POLL AND KQUEUE AND PIPE 1 TEST ***
nexus0: 
test select timeout
test select connect
worker: create new connect socket
worker: connect
test select read
worker: write
test select write
worker: read
test select close
worker: close
test poll timeout
test poll connect
worker: create new connect socket
worker: connect
test poll read
worker: write
test poll write
worker: read
test poll close
worker: close
test kqueue timer
test kqueue timer
test kqueue connect
worker: create new connect socket
worker: connect
test kqueue read
worker: write
test kqueue write
worker: read
test kqueue close
worker: shutdown
test kqueue user
test pipe timeout
test pipe read
worker: write
test pipe write
worker: read
test pipe close
worker: close pipe
Stack usage by thread
ID  NAMELOW  HIGH CURRENT AVAILABLE USED
0x09010001  IDLE 0x124250 - 0x12524f 0x125108  4080444
0x0a010001  UI1  0x1254b0 - 0x12d4af 0x12d138 32752   4224
0x0a010002  TIME 0x12dc08 - 0x135c07 0x135b00 32752564
0x0a010003  IRQS 0x135c10 - 0x13dc0f 0x13db10 32752556
0x0a010004  _BSD 0x1501c8 - 0x1581c7 0x1580d0 32752   1284
0x0a010005  _BSD 0x158318 - 0x160317 0x160220 32752700
0x0a010006  _BSD 0x161430 - 0x16942f 0x169338 32752548
0x0a010007  _BSD 0x1694f0 - 0x1714ef 0x171418 32752516
0x0a010008  _BSD 0x171688 - 0x179687 0x179590 32752548
0x0a010009  _BSD 0x179748 - 0x181747 0x181670 32752516
0x0a01000a  WORK 0x1a06c8 - 0x1a16c7 0x1a1568  4080   1020
*** END OF TEST LIBBSD SELECT AND POLL AND KQUEUE AND PIPE 1 ***

Kevin Kirspel
Electrical Engineer - Sr. Staff
Idexx Roswell
235 Hembree Park Drive
Roswell GA 30076
Tel: (770)-510- ext. 81642
Direct: (770)-688-1642
Fax: (770)-510-4445

-Original Message-
From: Sebastian Huber [mailto:sebastian.hu...@embedded-brains.de] 
Sent: Thursday, December 15, 2016 3:52 AM
To: Kirspel, Kevin ; devel@rtems.org
Subject: Re: [PATCH 1/7] Adding pipe support

Hello Kevin,

looks good so far (except one white space change, which I will fix for you, 
white space changes may lead to merge conflicts during a FreeBSD update). 
However, the "LIBBSD SELECT AND POLL AND KQUEUE AND PIPE 1 TEST" fails:

qemu-system-arm -no-reboot -serial null -serial mon:stdio -net none -nographic 
-M xilinx-zynq-a9 -m 256M -kernel 
build/arm-rtems4.12-xilinx_zynq_a9_qemu/selectpollkqueue01.exe
Warning: nic cadence_gem.0 has no peer
Warning: nic cadence_gem.1 has no peer
*** LIBBSD SELECT AND POLL AND KQUEUE AND PIPE 1 TEST ***
nexus0: 
test select timeout
test select connect
worker: create new connect socket
worker: connect
test select read
worker: write
test select write
worker: read
test select close
worker: close
test poll timeout
test poll connect
worker: create new connect socket
worker: connect
test poll read
worker: write
test poll write
worker: read
test poll close
worker: close
test kqueue timer
test kqueue timer
test kqueue connect
worker: create new connect socket
worker: connect
test kqueue read
worker: write
test kqueue write
worker: read
test kqueue close
worker: shutdown
test kqueue user
test pipe timeout
assertion "rv == 0" failed: file
"../../testsuite/selectpollkqueue01/test_main.c", line 1057, function: 
test_pipe_timeout

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

[PATCH 07/10] Add warning to Timer Driver chapter

[Sebastian Huber]

Move Timer Driver chapter.

Update #2847.
---
 bsp-howto/index.rst | 2 +-
 bsp-howto/timer.rst | 5 +
 2 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/bsp-howto/index.rst b/bsp-howto/index.rst
index ac0d5c0..68a9c35 100644
--- a/bsp-howto/index.rst
+++ b/bsp-howto/index.rst
@@ -49,11 +49,11 @@ to the Community Project hosted at http://www.rtems.org.
clock
i2c
spi
-   timer
real_time_clock
networking
shared_memory_support
frame_buffer
+   timer
ata
ide_controller
command
diff --git a/bsp-howto/timer.rst b/bsp-howto/timer.rst
index f0ec09b..b5e6bb6 100644
--- a/bsp-howto/timer.rst
+++ b/bsp-howto/timer.rst
@@ -7,6 +7,11 @@
 Timer Driver
 
 
+.. warning::
+
+   The Timer Driver is superfluous and should be replaced by the RTEMS counter
+   support.  Ask on the mailing list if you plan to write a Timer Driver.
+
 The timer driver is primarily used by the RTEMS Timing Tests.  This driver
 provides as accurate a benchmark timer as possible.  It typically reports its
 time in microseconds, CPU cycles, or bus cycles.  This information can be very
-- 
1.8.4.5

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH 10/10] Add warnings to basic BSP chapters

[Sebastian Huber]

Update #2852.
---
 bsp-howto/initilization_code.rst | 4 
 bsp-howto/linker_script.rst  | 4 
 bsp-howto/makefiles.rst  | 4 
 bsp-howto/miscellanous_support.rst   | 4 
 bsp-howto/target_dependant_files.rst | 4 
 5 files changed, 20 insertions(+)

diff --git a/bsp-howto/initilization_code.rst b/bsp-howto/initilization_code.rst
index 85bc10b..3dacaa7 100644
--- a/bsp-howto/initilization_code.rst
+++ b/bsp-howto/initilization_code.rst
@@ -7,6 +7,10 @@
 Initialization Code
 ***
 
+.. warning::
+
+   This chapter contains outdated and confusing information.
+
 Introduction
 
 
diff --git a/bsp-howto/linker_script.rst b/bsp-howto/linker_script.rst
index 1940ae8..c00d205 100644
--- a/bsp-howto/linker_script.rst
+++ b/bsp-howto/linker_script.rst
@@ -8,6 +8,10 @@
 Linker Script
 *
 
+.. warning::
+
+   This chapter contains outdated and confusing information.
+
 What is a "linkcmds" file?
 ==
 
diff --git a/bsp-howto/makefiles.rst b/bsp-howto/makefiles.rst
index b7ca12f..cd0feaf 100644
--- a/bsp-howto/makefiles.rst
+++ b/bsp-howto/makefiles.rst
@@ -9,6 +9,10 @@
 Makefiles
 *
 
+.. warning::
+
+   This chapter contains outdated and confusing information.
+
 This chapter discusses the Makefiles associated with a BSP.  It does not
 describe the process of configuring, building, and installing RTEMS.  This
 chapter will not provide detailed information about this process.  Nonetheless,
diff --git a/bsp-howto/miscellanous_support.rst 
b/bsp-howto/miscellanous_support.rst
index 1986bb6..75e5e1f 100644
--- a/bsp-howto/miscellanous_support.rst
+++ b/bsp-howto/miscellanous_support.rst
@@ -8,6 +8,10 @@
 Miscellaneous Support Files
 ***
 
+.. warning::
+
+   This chapter contains outdated and confusing information.
+
 GCC Compiler Specifications File
 
 
diff --git a/bsp-howto/target_dependant_files.rst 
b/bsp-howto/target_dependant_files.rst
index 2f15094..fdfe5d2 100644
--- a/bsp-howto/target_dependant_files.rst
+++ b/bsp-howto/target_dependant_files.rst
@@ -8,6 +8,10 @@
 Target Dependent Files
 **
 
+.. warning::
+
+   This chapter contains outdated and confusing information.
+
 RTEMS has a multi-layered approach to portability. This is done to maximize the
 amount of software that can be reused. Much of the RTEMS source code can be
 reused on all RTEMS platforms. Other parts of the executive are specific to
-- 
1.8.4.5

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH 04/10] Remove Discrete Driver chapter

[Sebastian Huber]

There exists no standard Discrete Driver in the RTEMS code base.

Close #2851.
---
 bsp-howto/discrete.rst | 190 -
 bsp-howto/index.rst|   1 -
 2 files changed, 191 deletions(-)
 delete mode 100644 bsp-howto/discrete.rst

diff --git a/bsp-howto/discrete.rst b/bsp-howto/discrete.rst
deleted file mode 100644
index 6607882..000
--- a/bsp-howto/discrete.rst
+++ /dev/null
@@ -1,190 +0,0 @@
-.. comment SPDX-License-Identifier: CC-BY-SA-4.0
-
-Discrete Driver
-***
-
-The Discrete driver is responsible for providing an interface to Discrete
-Input/Outputs.  The capabilities provided by this class of device driver are:
-
-- Initialize a Discrete I/O Board
-
-- Open a Particular Discrete Bitfield
-
-- Close a Particular Discrete Bitfield
-
-- Read from a Particular Discrete Bitfield
-
-- Write to a Particular Discrete Bitfield
-
-- Reset DACs
-
-- Reinitialize DACS
-
-Most discrete I/O devices are found on I/O cards that support many bits of
-discrete I/O on a single card.  This driver model is centered on the notion of
-reading bitfields from the card.
-
-There are currently no discrete I/O device drivers included in the RTEMS source
-tree.  The information provided in this chapter is based on drivers developed
-for applications using RTEMS.  It is hoped that this driver model information
-can form the discrete I/O driver model that can be supported in future RTEMS
-distribution.
-
-Major and Minor Numbers
-===
-
-The ``major`` number of a device driver is its index in the RTEMS Device
-Address Table.
-
-A ``minor`` number is associated with each device instance managed by a
-particular device driver.  An RTEMS minor number is an ``unsigned32`` entity.
-Convention calls for dividing the bits in the minor number down into categories
-that specify a particular bitfield.  This results in categories like the
-following:
-
-- ``board`` - indicates the board a particular bitfield is located on
-
-- ``word`` - indicates the particular word of discrete bits the bitfield is
-  located within
-
-- ``start`` - indicates the starting bit of the bitfield
-
-- ``width`` - indicates the width of the bitfield
-
-From the above, it should be clear that a single device driver can support
-multiple copies of the same board in a single system.  The minor number is used
-to distinguish the devices.
-
-By providing a way to easily access a particular bitfield from the device
-driver, the application is insulated with knowing how to mask fields in and out
-of a discrete I/O.
-
-Discrete I/O Driver Configuration
-=
-
-There is not a standard discrete I/O driver configuration table but some fields
-are common across different drivers.  The discrete I/O driver configuration
-table is typically an array of structures with each structure containing the
-information for a particular board.  The following is a list of the type of
-information normally required to configure an discrete I/O board:
-
-``board_offset``
-is the base address of a board.
-
-``relay_initial_values``
-is an array of the values that should be written to each output word on the
-board during initialization.  This allows the driver to start with the
-board's output in a known state.
-
-Initialize a Discrete I/O Board
-===
-
-At system initialization, the discrete I/O driver's initialization entry point
-will be invoked.  As part of initialization, the driver will perform whatever
-board initializatin is required and then set all outputs to their configured
-initial state.
-
-The discrete I/O driver may register a device name for bitfields of particular
-interest to the system.  Normally this will be restricted to the names of each
-word and, if the driver supports it, an "all words".
-
-Open a Particular Discrete Bitfield
-===
-
-This is the driver open call.  Usually this call does nothing other than
-validate the minor number.
-
-With some drivers, it may be necessary to allocate memory when a particular
-device is opened.  If that is the case, then this is often the place to do this
-operation.
-
-Close a Particular Discrete Bitfield
-
-
-This is the driver close call.  Usually this call does nothing.
-
-With some drivers, it may be necessary to allocate memory when a particular
-device is opened.  If that is the case, then this is the place where that
-memory should be deallocated.
-
-Read from a Particular Discrete Bitfield
-
-
-This corresponds to the driver read call.  After validating the minor number
-and arguments, this call reads the indicated bitfield.  A discrete I/O devices
-may have to store the last value written to a discrete output.  If the bitfield
-is output only, saving the last written value gives the appearance that it can
-be read from also.  If the bitfield is input, then it is 

[PATCH 09/10] Move Shared Memory Support Driver chapter

[Sebastian Huber]

This chapter is very specific.  Move it to a less prominent chapter
position.
---
 bsp-howto/index.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bsp-howto/index.rst b/bsp-howto/index.rst
index 72e0b23..921a916 100644
--- a/bsp-howto/index.rst
+++ b/bsp-howto/index.rst
@@ -50,9 +50,9 @@ to the Community Project hosted at http://www.rtems.org.
spi
real_time_clock
networking
-   shared_memory_support
frame_buffer
ada95_interrupt
+   shared_memory_support
timer
ata
ide_controller
-- 
1.8.4.5

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH 02/10] Document I2C framework

[Sebastian Huber]

Update #2845.
---
 bsp-howto/i2c.rst   | 19 +++
 bsp-howto/index.rst |  1 +
 2 files changed, 20 insertions(+)
 create mode 100644 bsp-howto/i2c.rst

diff --git a/bsp-howto/i2c.rst b/bsp-howto/i2c.rst
new file mode 100644
index 000..caa78e1
--- /dev/null
+++ b/bsp-howto/i2c.rst
@@ -0,0 +1,19 @@
+.. comment SPDX-License-Identifier: CC-BY-SA-4.0
+
+.. COMMENT: Copyright (c) 2016 embedded brains GmbH 
+.. COMMENT: All rights reserved.
+
+I2C Driver
+**
+
+The Inter-Integrated Circuit (I2C, I??C, IIC) bus drivers should use the
+`I2C bus framework 
`_.
+For example drivers see the
+`Cadence I2C driver 
`_,
+the
+`Atmel SAM I2C driver 
`_
+and the
+`I2C framework test 
`_.
+
+The user API is compatible to the
+`Linux I2C user-space API 
`_.
diff --git a/bsp-howto/index.rst b/bsp-howto/index.rst
index f1c3a4e..649e335 100644
--- a/bsp-howto/index.rst
+++ b/bsp-howto/index.rst
@@ -47,6 +47,7 @@ to the Community Project hosted at http://www.rtems.org.
initilization_code
console
clock
+   i2c
spi
timer
real_time_clock
-- 
1.8.4.5

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH 06/10] Add warning to ATA/IDE driver chapter

[Sebastian Huber]

Close #2849.
---
 bsp-howto/ata.rst| 7 +++
 bsp-howto/ide_controller.rst | 7 +++
 bsp-howto/index.rst  | 4 ++--
 3 files changed, 16 insertions(+), 2 deletions(-)

diff --git a/bsp-howto/ata.rst b/bsp-howto/ata.rst
index 9416a80..7e7e2e8 100644
--- a/bsp-howto/ata.rst
+++ b/bsp-howto/ata.rst
@@ -7,6 +7,13 @@
 ATA Driver
 **
 
+.. warning::
+
+   The ATA/IDE Drivers are out of date and should not be used for new BSPs.
+   The preferred alternative is to port the ATA/SATA/SCSI/NVMe support from
+   FreeBSD to RTEMS using the `libbsd `_.
+   Ask on the mailing list if you plan to write a driver for an ATA/IDE device.
+
 Terms
 =
 
diff --git a/bsp-howto/ide_controller.rst b/bsp-howto/ide_controller.rst
index c5e4435..101c962 100644
--- a/bsp-howto/ide_controller.rst
+++ b/bsp-howto/ide_controller.rst
@@ -7,6 +7,13 @@
 IDE Controller Driver
 *
 
+.. warning::
+
+   The ATA/IDE Drivers are out of date and should not be used for new BSPs.
+   The preferred alternative is to port the ATA/SATA/SCSI/NVMe support from
+   FreeBSD to RTEMS using the `libbsd `_.
+   Ask on the mailing list if you plan to write a driver for an ATA/IDE device.
+
 Introduction
 
 
diff --git a/bsp-howto/index.rst b/bsp-howto/index.rst
index d826369..ac0d5c0 100644
--- a/bsp-howto/index.rst
+++ b/bsp-howto/index.rst
@@ -51,11 +51,11 @@ to the Community Project hosted at http://www.rtems.org.
spi
timer
real_time_clock
-   ata
-   ide_controller
networking
shared_memory_support
frame_buffer
+   ata
+   ide_controller
command
 
 *  :ref:`genindex`
-- 
1.8.4.5

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH 01/10] Document SPI framework

[Sebastian Huber]

Update #2776.
---
 bsp-howto/index.rst |  1 +
 bsp-howto/spi.rst   | 19 +++
 2 files changed, 20 insertions(+)
 create mode 100644 bsp-howto/spi.rst

diff --git a/bsp-howto/index.rst b/bsp-howto/index.rst
index 71c5e1b..f1c3a4e 100644
--- a/bsp-howto/index.rst
+++ b/bsp-howto/index.rst
@@ -47,6 +47,7 @@ to the Community Project hosted at http://www.rtems.org.
initilization_code
console
clock
+   spi
timer
real_time_clock
ata
diff --git a/bsp-howto/spi.rst b/bsp-howto/spi.rst
new file mode 100644
index 000..5a6d931
--- /dev/null
+++ b/bsp-howto/spi.rst
@@ -0,0 +1,19 @@
+.. comment SPDX-License-Identifier: CC-BY-SA-4.0
+
+.. COMMENT: Copyright (c) 2016 embedded brains GmbH 
+.. COMMENT: All rights reserved.
+
+SPI Driver
+**
+
+The Serial Peripheral Interface (SPI) bus drivers should use the
+`SPI bus framework
+`_.
+For
+example drivers see the
+`Atmel SAM SPI driver 
`_
+and the
+`SPI framework test 
`_.
+
+The user API is compatible to the
+`Linux SPI user-space API 
`_.
-- 
1.8.4.5

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH 03/10] Remove Analog Driver chapter

[Sebastian Huber]

There exists no standard Analog Driver in the RTEMS code base.

Close #2850.
---
 bsp-howto/analog.rst | 165 ---
 bsp-howto/index.rst  |   1 -
 2 files changed, 166 deletions(-)
 delete mode 100644 bsp-howto/analog.rst

diff --git a/bsp-howto/analog.rst b/bsp-howto/analog.rst
deleted file mode 100644
index 907e240..000
--- a/bsp-howto/analog.rst
+++ /dev/null
@@ -1,165 +0,0 @@
-.. comment SPDX-License-Identifier: CC-BY-SA-4.0
-
-.. COMMENT: COPYRIGHT (c) 1988-2002.
-.. COMMENT: On-Line Applications Research Corporation (OAR).
-.. COMMENT: All rights reserved.
-
-Analog Driver
-*
-
-The Analog driver is responsible for providing an interface to Digital to
-Analog Converters (DACs) and Analog to Digital Converters (ADCs).  The
-capabilities provided by this class of device driver are:
-
-- Initialize an Analog Board
-
-- Open a Particular Analog
-
-- Close a Particular Analog
-
-- Read from a Particular Analog
-
-- Write to a Particular Analog
-
-- Reset DACs
-
-- Reinitialize DACS
-
-Most analog devices are found on I/O cards that support multiple DACs or ADCs
-on a single card.
-
-There are currently no analog device drivers included in the RTEMS source tree.
-The information provided in this chapter is based on drivers developed for
-applications using RTEMS.  It is hoped that this driver model information can
-form the basis for a standard analog driver model that can be supported in
-future RTEMS distribution.
-
-Major and Minor Numbers
-===
-
-The ``major`` number of a device driver is its index in the RTEMS Device
-Address Table.
-
-A ``minor`` number is associated with each device instance managed by a
-particular device driver.  An RTEMS minor number is an ``unsigned32`` entity.
-Convention calls for dividing the bits in the minor number down into categories
-like the following:
-
-- ``board`` - indicates the board a particular device is located on
-
-- ``port`` - indicates the particular device on a board.
-
-From the above, it should be clear that a single device driver can support
-multiple copies of the same board in a single system.  The minor number is used
-to distinguish the devices.
-
-Analog Driver Configuration
-===
-
-There is not a standard analog driver configuration table but some fields are
-common across different drivers.  The analog driver configuration table is
-typically an array of structures with each structure containing the information
-for a particular board.  The following is a list of the type of information
-normally required to configure an analog board:
-
-``board_offset``
-is the base address of a board.
-
-``DAC_initial_values``
-is an array of the voltages that should be written to each DAC during
-initialization.  This allows the driver to start the board in a known
-state.
-
-Initialize an Analog Board
-==
-
-At system initialization, the analog driver's initialization entry point will
-be invoked.  As part of initialization, the driver will perform whatever board
-initialization is required and then set all outputs to their configured initial
-state.
-
-The analog driver may register a device name for each DAC and ADC in the
-system.
-
-Open a Particular Analog
-
-
-This is the driver open call.  Usually this call does nothing other than
-validate the minor number.
-
-With some drivers, it may be necessary to allocate memory when a particular
-device is opened.  If that is the case, then this is often the place to do this
-operation.
-
-Close a Particular Analog
-=
-
-This is the driver close call.  Usually this call does nothing.
-
-With some drivers, it may be necessary to allocate memory when a particular
-device is opened.  If that is the case, then this is the place where that
-memory should be deallocated.
-
-Read from a Particular Analog
-=
-
-This corresponds to the driver read call.  After validating the minor number
-and arguments, this call reads the indicated device.  Most analog devices store
-the last value written to a DAC.  Since DACs are output only devices, saving
-the last written value gives the appearance that DACs can be read from also.
-If the device is an ADC, then it is sampled.
-
-.. note::
-
-   Many boards have multiple analog inputs but only one ADC.  On these boards,
-   it will be necessary to provide some type of mutual exclusion during reads.
-   On these boards, there is a MUX which must be switched before sampling the
-   ADC.  After the MUX is switched, the driver must delay some short period of
-   time (usually microseconds) before the signal is stable and can be sampled.
-   To make matters worse, some ADCs cannot respond to wide voltage swings in a
-   single sample.  On these ADCs, one must do two samples when the voltage
-   swing is too large.  On a practical basis, this means that the driver
-   

[PATCH 05/10] Remove Non-Volatile Memory Driver chapter

[Sebastian Huber]

There exists no standard Non-Volatile Memory Driver in the RTEMS code
base.

Close #2851.
---
 bsp-howto/index.rst   |   1 -
 bsp-howto/non_volatile_memory.rst | 217 --
 2 files changed, 218 deletions(-)
 delete mode 100644 bsp-howto/non_volatile_memory.rst

diff --git a/bsp-howto/index.rst b/bsp-howto/index.rst
index f99118d..d826369 100644
--- a/bsp-howto/index.rst
+++ b/bsp-howto/index.rst
@@ -53,7 +53,6 @@ to the Community Project hosted at http://www.rtems.org.
real_time_clock
ata
ide_controller
-   non_volatile_memory
networking
shared_memory_support
frame_buffer
diff --git a/bsp-howto/non_volatile_memory.rst 
b/bsp-howto/non_volatile_memory.rst
deleted file mode 100644
index e23c162..000
--- a/bsp-howto/non_volatile_memory.rst
+++ /dev/null
@@ -1,217 +0,0 @@
-.. comment SPDX-License-Identifier: CC-BY-SA-4.0
-
-.. COMMENT: Written by Eric Norum
-.. COMMENT: COPYRIGHT (c) 1988-2002.
-.. COMMENT: On-Line Applications Research Corporation (OAR).
-.. COMMENT: All rights reserved.
-
-Non-Volatile Memory Driver
-**
-
-The Non-Volatile driver is responsible for providing an interface to various
-types of non-volatile memory.  These types of memory include, but are not
-limited to, Flash, EEPROM, and battery backed RAM.  The capabilities provided
-by this class of device driver are:
-
-- Initialize the Non-Volatile Memory Driver
-
-- Optional Disable Read and Write Handlers
-
-- Open a Particular Memory Partition
-
-- Close a Particular Memory Partition
-
-- Read from a Particular Memory Partition
-
-- Write to a Particular Memory Partition
-
-- Erase the Non-Volatile Memory Area
-
-There is currently only one non-volatile device driver included in the RTEMS
-source tree.  The information provided in this chapter is based on drivers
-developed for applications using RTEMS.  It is hoped that this driver model
-information can form the basis for a standard non-volatile memory driver model
-that can be supported in future RTEMS distribution.
-
-Major and Minor Numbers
-===
-
-The ``major`` number of a device driver is its index in the RTEMS Device
-Address Table.
-
-A ``minor`` number is associated with each device instance managed by a
-particular device driver.  An RTEMS minor number is an ``unsigned32`` entity.
-Convention calls dividing the bits in the minor number down into categories
-that specify an area of non-volatile memory and a partition with that area.
-This results in categories like the following:
-
-- ``area`` - indicates a block of non-volatile memory
-
-- ``partition`` - indicates a particular address range with an area
-
-From the above, it should be clear that a single device driver can support
-multiple types of non-volatile memory in a single system.  The minor number is
-used to distinguish the types of memory and blocks of memory used for different
-purposes.
-
-Non-Volatile Memory Driver Configuration
-
-
-There is not a standard non-volatile driver configuration table but some fields
-are common across different drivers.  The non-volatile memory driver
-configuration table is typically an array of structures with each structure
-containing the information for a particular area of non-volatile memory.  The
-following is a list of the type of information normally required to configure
-each area of non-volatile memory.
-
-``memory_type``
-is the type of memory device in this area.  Choices are battery backed RAM,
-EEPROM, Flash, or an optional user-supplied type.  If the user-supplied
-type is configured, then the user is responsible for providing a set of
-routines to program the memory.
-
-``memory``
-is the base address of this memory area.
-
-``attributes``
-is a pointer to a memory type specific attribute block.  Some of the fields
-commonly contained in this memory type specific attribute structure area:
-
-``use_protection_algorithm``
-is set to TRUE to indicate that the protection (i.e. locking) algorithm
-should be used for this area of non-volatile memory.  A particular type
-of non-volatile memory may not have a protection algorithm.
-
-``access``
-is an enumerated type to indicate the organization of the memory
-devices in this memory area.  The following is a list of the access
-types supported by the current driver implementation:
-
-  - simple unsigned8
-  - simple unsigned16
-  - simple unsigned32
-  - simple unsigned64
-  - single unsigned8 at offset 0 in an unsigned16
-  - single unsigned8 at offset 1 in an unsigned16
-  - single unsigned8 at offset 0 in an unsigned32
-  - single unsigned8 at offset 1 in an unsigned32
-  - single unsigned8 at offset 2 in an unsigned32
-  - single unsigned8 at offset 3 in an unsigned32
-
-   

[PATCH] RTEMS: Add user-defined name to thread queues

[Sebastian Huber]

Add a user-defined name to the self-contained synchronization objects in
order to make system diagnostics, tracing and debugging more user
friendly.

Signed-off-by: Sebastian Huber 
---
 newlib/libc/sys/rtems/include/sys/lock.h | 21 -
 1 file changed, 20 insertions(+), 1 deletion(-)

diff --git a/newlib/libc/sys/rtems/include/sys/lock.h 
b/newlib/libc/sys/rtems/include/sys/lock.h
index c0549db..663d672 100644
--- a/newlib/libc/sys/rtems/include/sys/lock.h
+++ b/newlib/libc/sys/rtems/include/sys/lock.h
@@ -46,6 +46,7 @@ struct _Thread_queue_Queue {
struct _Ticket_lock_Control _Lock;
struct _Thread_queue_Heads *_heads;
struct _Thread_Control *_owner;
+   const char *_name;
 };
 
 struct _Mutex_Control {
@@ -72,18 +73,36 @@ struct _Futex_Control {
 
 #define _TICKET_LOCK_INITIALIZER { 0, 0 }
 
-#define _THREAD_QUEUE_INITIALIZER { _TICKET_LOCK_INITIALIZER, 0, 0 }
+#define _THREAD_QUEUE_INITIALIZER { _TICKET_LOCK_INITIALIZER, 0, 0, 0 }
+
+#define _THREAD_QUEUE_NAMED_INITIALIZER(_name) \
+{ _TICKET_LOCK_INITIALIZER, 0, 0, _name }
 
 #define _MUTEX_INITIALIZER { _THREAD_QUEUE_INITIALIZER }
 
+#define _MUTEX_NAMED_INITIALIZER(_name) \
+{ _THREAD_QUEUE_NAMED_INITIALIZER(_name) }
+
 #define _MUTEX_RECURSIVE_INITIALIZER { _MUTEX_INITIALIZER, 0 }
 
+#define _MUTEX_RECURSIVE_NAMED_INITIALIZER(_name) \
+{ _MUTEX_NAMED_INITIALIZER(_name), 0 }
+
 #define _CONDITION_INITIALIZER { _THREAD_QUEUE_INITIALIZER }
 
+#define _CONDITION_NAMED_INITIALIZER(_name) \
+{ _THREAD_QUEUE_NAMED_INITIALIZER(_name) }
+
 #define _SEMAPHORE_INITIALIZER(_count) { _THREAD_QUEUE_INITIALIZER, _count }
 
+#define _SEMAPHORE_NAMED_INITIALIZER(_name, _count) \
+{ _THREAD_QUEUE_NAMED_INITIALIZER(_name), _count }
+
 #define _FUTEX_INITIALIZER { _THREAD_QUEUE_INITIALIZER }
 
+#define _FUTEX_NAMED_INITIALIZER(_name) \
+{ _THREAD_QUEUE_NAMED_INITIALIZER(_name) }
+
 static __inline void
 _Mutex_Initialize(struct _Mutex_Control *_mutex)
 {
-- 
1.8.4.5

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel