[PATCH 2/2] testsuite/rcxx01: Add examples for use in the User manual

2020-10-08 Thread chrisj 
From: Chris Johns 

---
 spec/build/testsuites/libtests/rcxx01.yml |   3 +
 testsuites/libtests/rcxx01/init.c |   2 +-
 testsuites/libtests/rcxx01/thread.cpp |  21 +++-
 testsuites/libtests/rcxx01/user-example-1.cpp |  49 
 testsuites/libtests/rcxx01/user-example-2.cpp |  68 +++
 testsuites/libtests/rcxx01/user-example-3.cpp | 113 ++
 6 files changed, 251 insertions(+), 5 deletions(-)
 create mode 100644 testsuites/libtests/rcxx01/user-example-1.cpp
 create mode 100644 testsuites/libtests/rcxx01/user-example-2.cpp
 create mode 100644 testsuites/libtests/rcxx01/user-example-3.cpp

diff --git a/spec/build/testsuites/libtests/rcxx01.yml 
b/spec/build/testsuites/libtests/rcxx01.yml
index 864ad4d9d6..49bd9cff66 100644
--- a/spec/build/testsuites/libtests/rcxx01.yml
+++ b/spec/build/testsuites/libtests/rcxx01.yml
@@ -13,6 +13,9 @@ links: []
 source:
 - testsuites/libtests/rcxx01/init.c
 - testsuites/libtests/rcxx01/thread.cpp
+- testsuites/libtests/rcxx01/user-example-1.cpp
+- testsuites/libtests/rcxx01/user-example-2.cpp
+- testsuites/libtests/rcxx01/user-example-3.cpp
 stlib: []
 target: testsuites/libtests/rcxx01.exe
 type: build
diff --git a/testsuites/libtests/rcxx01/init.c 
b/testsuites/libtests/rcxx01/init.c
index 87d3155c7f..bea71d14c7 100644
--- a/testsuites/libtests/rcxx01/init.c
+++ b/testsuites/libtests/rcxx01/init.c
@@ -72,7 +72,7 @@ rtems_task Init(
 #define CONFIGURE_MEMORY_OVERHEAD (2024)
 
 #define CONFIGURE_MAXIMUM_TASKS  1
-#define CONFIGURE_MAXIMUM_POSIX_THREADS 2
+#define CONFIGURE_MAXIMUM_POSIX_THREADS 5
 
 #define CONFIGURE_INITIAL_EXTENSIONS RTEMS_TEST_INITIAL_EXTENSION
 
diff --git a/testsuites/libtests/rcxx01/thread.cpp 
b/testsuites/libtests/rcxx01/thread.cpp
index 05a9de8c48..f977a340a9 100644
--- a/testsuites/libtests/rcxx01/thread.cpp
+++ b/testsuites/libtests/rcxx01/thread.cpp
@@ -36,6 +36,10 @@ using namespace std::chrono_literals;
 
 extern "C" void rcxx_run_test(void);
 
+void example_1();
+void example_2();
+void example_3();
+
 struct test_thread
 {
   test_thread();
@@ -96,13 +100,22 @@ bool test_thread::running()
   return finished == false;
 }
 
+void test_1()
+{
+  test_thread tt;
+  tt.start();
+  while (tt.running())
+std::this_thread::sleep_for(1s);
+}
+
 void rcxx_run_test(void)
 {
   try {
-test_thread tt;
-tt.start();
-while (tt.running())
-  std::this_thread::sleep_for(1s);
+test_1();
+/* From the user manual */
+example_1();
+example_2();
+example_3();
   } catch (...) {
 std::cout << "Thread: ouch" << std::endl;
 throw;
diff --git a/testsuites/libtests/rcxx01/user-example-1.cpp 
b/testsuites/libtests/rcxx01/user-example-1.cpp
new file mode 100644
index 00..dfc0992193
--- /dev/null
+++ b/testsuites/libtests/rcxx01/user-example-1.cpp
@@ -0,0 +1,49 @@
+/* SPDX-License-Identifier: BSD-2-Clause */
+
+/*
+ * Copyright (C) 2020 Chris Johns (http://contemporary.software)
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in the
+ *documentation and/or other materials provided with the distribution.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
+ * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE
+ * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
+ * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
+ * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
+ * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
+ * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
+ * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
+ * POSSIBILITY OF SUCH DAMAGE.
+ */
+
+#include 
+#include 
+
+#include 
+
+static void wait_for(size_t seconds)
+{
+  while (seconds--) {
+std::this_thread::sleep_for(std::chrono::seconds(1));
+std::cout << "Seconds: " << seconds << std::endl;
+  }
+}
+
+void example_1()
+{
+  std::cout << "Start example 1" << std::endl;
+
+  rtems::thread::thread t(wait_for, 5);
+  t.join();
+
+  std::cout << "End example 1" << std::endl;
+}
diff --git a/testsuites/libtests/rcxx01/user-example-2.cpp 
b/testsuites/libtests/rcxx01/user-example-2.cpp
new file mode 100644
index 00..05090fc73c
--- /dev/null
+++ b/testsuites/libtests/rcxx01/user-example-2.cpp
@@ -0,0 +1,68 @@
+/* SPDX-License-Identifier: BSD-2-Clause */
+
+/*
+ * C

[PATCH 1/2] librtemsc++: Add join() and detach() to the thread

2020-10-08 Thread chrisj 
From: Chris Johns 

- Do not start threads detached
---
 cpukit/include/rtems/thread.hpp |  4 
 cpukit/librtemscxx/thread.cpp   | 22 ++
 2 files changed, 22 insertions(+), 4 deletions(-)

diff --git a/cpukit/include/rtems/thread.hpp b/cpukit/include/rtems/thread.hpp
index e90e664dfa..2c4899dc0b 100644
--- a/cpukit/include/rtems/thread.hpp
+++ b/cpukit/include/rtems/thread.hpp
@@ -321,6 +321,10 @@ namespace rtems
 
   bool joinable() const noexcept;
 
+  void join() noexcept;
+
+  void detach() noexcept;
+
   /*
* Constrain use. These are not available.
*/
diff --git a/cpukit/librtemscxx/thread.cpp b/cpukit/librtemscxx/thread.cpp
index 11bf3df230..ae13201bd4 100644
--- a/cpukit/librtemscxx/thread.cpp
+++ b/cpukit/librtemscxx/thread.cpp
@@ -346,6 +346,24 @@ namespace rtems
   return !(id_ == id());
 }
 
+void
+thread::join() noexcept
+{
+  if (!joinable())
+system_error_check (ENOMEM, "join");
+  system_error_check (::pthread_join (id_.id_, nullptr), "join");
+  id_ = id();
+}
+
+void
+thread::detach() noexcept
+{
+  if (!joinable())
+system_error_check (EINVAL, "detach");
+  system_error_check (::pthread_detach (id_.id_), "detach");
+  id_ = id();
+}
+
 thread::state_base::~state_base () = default;
 
 void
@@ -358,10 +376,6 @@ namespace rtems
   system_error_check (::pthread_attr_init (&pattr),
   "attribute init");
 
-  system_error_check (::pthread_attr_setdetachstate (&pattr,
- 
PTHREAD_CREATE_DETACHED),
-  "set detached state");
-
   struct sched_param param;
   param.sched_priority = attr.get_priority ();
   system_error_check (::pthread_attr_setschedparam (&pattr, ¶m),
-- 
2.24.1

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

Re: Documentation image source

2020-10-08 Thread Joel Sherrill 
Dot can produce svg

dot -Tsvg graph.dot -o file

PlantUML appears to use -tsvg

Does that help?

On Thu, Oct 8, 2020, 1:39 AM Chris Johns  wrote:

> On 8/10/20 5:30 pm, Sebastian Huber wrote:
> > On 08/10/2020 08:18, Chris Johns wrote:
> >> On 8/10/20 4:31 pm, Sebastian Huber wrote:
> >>> On 08/10/2020 03:01, Chris Johns wrote:
> >>>
>  I see generated .png and .pdf for some images which I am questioning
> we need.
>  The user document images I have contributed are only .png files so I
> am not
>  sure
>  why a PDF is needed for some.
> >>> Images in a vector format is very important for a high quality PDF.
> Using PNG
> >>> for the PDFs is not really good.
> >> Yes is does help but I am not convinced by the "very important" bit. I
> looked at
> >> the user manual executable pictures in the PDF at 400% on a quality
> monitor and
> >> they hold up nicely. All you get to see is the anti-aliasing effects
> which is
> >> understandable.
> >>
> >> HTML and PDF need to be at the same quality level and I have shown this
> can be
> >> achieved even with .png files. PDF is not something we should treat as
> special.
> >> At the moment I cannot read the dot HTML images.
> >>
> >> The PDF quality depends on the contents of the PDF fragment. It may not
> always
> >> be vectors so I am not sure we can assume this. I have seen PDF get
> abused with
> >> horrible results. It looks like .dot is vector which is fine.
> >>
> >> Manual generation is something I would like to avoid and especially if
> more than
> >> one output file type is being generated. The poor HTML quality of the
> dot
> >> generated .png files highlights this. Can they please be improved?
> > It would be nice to use a vector format for HTML also. Maybe we should
> use SVG
> > instead of PNG.
>
> That would be a nice solution but I have no idea how to do that. It would
> have
> to work on all browsers on all devices. That is an area where the less I
> know
> the happier I am. Is simpler better in this case, that is a suitably size
> image?
>
> 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: [PATCH] grlib: Add and use irqmp_has_timestamp()

2020-10-08 Thread Joel Sherrill 
Looks OK to push.

Do you want to cite the ticket number for the build failures in the
comments?

Should I go ahead and push the fatal error patch or will you do that?

Is this needed on 5? I thought these all built on 5 but could be wrong.

On Thu, Oct 8, 2020 at 12:52 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> Replace leon3_irqmp_has_timestamp() with irqmp_has_timestamp() and move
> it to grlib.h.
>
> Close #4128.
> ---
>  bsps/riscv/griscv/clock/clockdrv.c | 2 +-
>  bsps/shared/grlib/btimer/tlib_ckinit.c | 2 +-
>  bsps/sparc/leon3/clock/ckinit.c| 4 ++--
>  bsps/sparc/leon3/include/leon.h| 7 ---
>  bsps/sparc/leon3/start/cpucounter.c| 2 +-
>  5 files changed, 5 insertions(+), 12 deletions(-)
>
> diff --git a/bsps/riscv/griscv/clock/clockdrv.c
> b/bsps/riscv/griscv/clock/clockdrv.c
> index c94c167fdf..4cf15fe4f8 100644
> --- a/bsps/riscv/griscv/clock/clockdrv.c
> +++ b/bsps/riscv/griscv/clock/clockdrv.c
> @@ -171,7 +171,7 @@ static void grlib_clock_initialize(void)
>volatile struct irqmp_timestamp_regs *irqmp_ts =
>  &GRLIB_IrqCtrl_Regs->timestamp[0];
>
> -if (!grlib_irqmp_has_timestamp(irqmp_ts)) {
> +if (!irqmp_has_timestamp(irqmp_ts)) {
>bsp_fatal(GRLIB_FATAL_CLOCK_NO_IRQMP_TIMESTAMP_SUPPORT);
>  }
>  #endif
> diff --git a/bsps/shared/grlib/btimer/tlib_ckinit.c
> b/bsps/shared/grlib/btimer/tlib_ckinit.c
> index 4f679984d8..5a34d97c00 100644
> --- a/bsps/shared/grlib/btimer/tlib_ckinit.c
> +++ b/bsps/shared/grlib/btimer/tlib_ckinit.c
> @@ -126,7 +126,7 @@ static rtems_device_driver tlib_clock_find_timer(void)
>  volatile struct irqmp_timestamp_regs *irqmp_ts;
>
>  irqmp_ts = &LEON3_IrqCtrl_Regs->timestamp[0];
> -if (leon3_irqmp_has_timestamp(irqmp_ts)) {
> +if (irqmp_has_timestamp(irqmp_ts)) {
>priv.ops = &ops_irqamp;
>return RTEMS_SUCCESSFUL;
>  }
> diff --git a/bsps/sparc/leon3/clock/ckinit.c
> b/bsps/sparc/leon3/clock/ckinit.c
> index f485123f6b..bf0c506ec0 100644
> --- a/bsps/sparc/leon3/clock/ckinit.c
> +++ b/bsps/sparc/leon3/clock/ckinit.c
> @@ -176,13 +176,13 @@ static void leon3_clock_initialize(void)
>  tc->tc_frequency = leon3_up_counter_frequency();
>
>  #ifdef RTEMS_PROFILING
> -if (!leon3_irqmp_has_timestamp(irqmp_ts)) {
> +if (!irqmp_has_timestamp(irqmp_ts)) {
>bsp_fatal(LEON3_FATAL_CLOCK_NO_IRQMP_TIMESTAMP_SUPPORT);
>  }
>  #endif
>
>  leon3_tc_tick = leon3_tc_tick_irqmp_timestamp_init;
> -  } else if (leon3_irqmp_has_timestamp(irqmp_ts)) {
> +  } else if (irqmp_has_timestamp(irqmp_ts)) {
>  /* Use the interrupt controller timestamp counter if available */
>  tc->tc_get_timecount = _SPARC_Get_timecount_up;
>  tc->tc_frequency = ambapp_freq_get(&ambapp_plb, LEON3_Timer_Adev);
> diff --git a/bsps/sparc/leon3/include/leon.h
> b/bsps/sparc/leon3/include/leon.h
> index afe0d91ca4..d25825c8e8 100644
> --- a/bsps/sparc/leon3/include/leon.h
> +++ b/bsps/sparc/leon3/include/leon.h
> @@ -454,13 +454,6 @@ static inline uint32_t
> leon3_get_data_cache_config_register(void)
>return leon3_get_system_register(0xc);
>  }
>
> -static inline bool leon3_irqmp_has_timestamp(
> -  volatile struct irqmp_timestamp_regs *irqmp_ts
> -)
> -{
> -  return (irqmp_ts->control >> 27) > 0;
> -}
> -
>  static inline uint32_t leon3_up_counter_low(void)
>  {
>uint32_t asr23;
> diff --git a/bsps/sparc/leon3/start/cpucounter.c
> b/bsps/sparc/leon3/start/cpucounter.c
> index 007bb6d8ec..1d96e3b221 100644
> --- a/bsps/sparc/leon3/start/cpucounter.c
> +++ b/bsps/sparc/leon3/start/cpucounter.c
> @@ -43,7 +43,7 @@ static void leon3_counter_initialize(void)
>  counter->read = _SPARC_Counter_read_asr23;
>
>  leon3_counter_frequency = leon3_up_counter_frequency();
> -  } else if (leon3_irqmp_has_timestamp(irqmp_ts)) {
> +  } else if (irqmp_has_timestamp(irqmp_ts)) {
>  /* Use the interrupt controller timestamp counter if available */
>  counter->read_isr_disabled = _SPARC_Counter_read_up;
>  counter->read = _SPARC_Counter_read_up;
> --
> 2.26.2
>
> ___
> 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/2] rtems: Add "Generated from ..." comments

2020-10-08 Thread Joel Sherrill 
On Wed, Oct 7, 2020 at 10:32 PM Chris Johns  wrote:

> On 8/10/20 2:18 pm, Joel Sherrill wrote:
> > On Wed, Oct 7, 2020, 10:14 PM Chris Johns  > > wrote:
> > On 7/10/20 9:14 pm, Sebastian Huber wrote:
> > > Improve file header comment.
> >
> > This is great.
> >
> > Agreed. I assume the spec: is defined somewhere.
>
> The patch has ...
>
> +/* Generated from spec:/rtems/if/group */
>
> and the file is ...
>
> https://git.rtems.org/rtems-central/tree/spec/rtems/if/group.yml


Awesome!

>
>
> These addition are a really good productivity improvement. It takes
> seconds to
> find the file and there is no guess work involved.
>

That definitely addresses a serious issue in maintaining anything that is
generated -- finding the spot to touch in the magical file it is generated
from.

Guess we will just have to be alert to where people struggle as we go
forward and make an effort to ensure questions are only asked once and
always answered with links to documentation.

--joel


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

Re: [PATCH] grlib: Add and use irqmp_has_timestamp()

2020-10-08 Thread Joel Sherrill 
I will push my fatal patch. Yours compiles but I see these warnings which
appear to be related:

 make -j >/dev/null
../../../../../../../../rtems/c/src/lib/libbsp/riscv/griscv/../../../../../../bsps/riscv/griscv/clock/clockdrv.c:
In function 'grlib_clock_initialize':
../../../../../../../../rtems/c/src/lib/libbsp/riscv/griscv/../../../../../../bsps/riscv/griscv/clock/clockdrv.c:174:10:
warning: implicit declaration of function 'grlib_irqmp_has_timestamp'
[-Wimplicit-function-declaration]
  174 | if (!grlib_irqmp_has_timestamp(irqmp_ts)) {
  |  ^
../../../../../../../../rtems/c/src/lib/libbsp/riscv/griscv/../../../../../../bsps/riscv/griscv/clock/clockdrv.c:174:10:
warning: nested extern declaration of 'grlib_irqmp_has_timestamp'
[-Wnested-externs]
../../../../../../../../rtems/c/src/lib/libbsp/riscv/griscv/../../../../../../bsps/shared/dev/flash/am29lv160.c:
In function 'rtems_am29lv160_write_data_8':

On Thu, Oct 8, 2020 at 8:09 AM Joel Sherrill  wrote:

> Looks OK to push.
>
> Do you want to cite the ticket number for the build failures in the
> comments?
>
> Should I go ahead and push the fatal error patch or will you do that?
>
> Is this needed on 5? I thought these all built on 5 but could be wrong.
>
> On Thu, Oct 8, 2020 at 12:52 AM Sebastian Huber <
> sebastian.hu...@embedded-brains.de> wrote:
>
>> Replace leon3_irqmp_has_timestamp() with irqmp_has_timestamp() and move
>> it to grlib.h.
>>
>> Close #4128.
>> ---
>>  bsps/riscv/griscv/clock/clockdrv.c | 2 +-
>>  bsps/shared/grlib/btimer/tlib_ckinit.c | 2 +-
>>  bsps/sparc/leon3/clock/ckinit.c| 4 ++--
>>  bsps/sparc/leon3/include/leon.h| 7 ---
>>  bsps/sparc/leon3/start/cpucounter.c| 2 +-
>>  5 files changed, 5 insertions(+), 12 deletions(-)
>>
>> diff --git a/bsps/riscv/griscv/clock/clockdrv.c
>> b/bsps/riscv/griscv/clock/clockdrv.c
>> index c94c167fdf..4cf15fe4f8 100644
>> --- a/bsps/riscv/griscv/clock/clockdrv.c
>> +++ b/bsps/riscv/griscv/clock/clockdrv.c
>> @@ -171,7 +171,7 @@ static void grlib_clock_initialize(void)
>>volatile struct irqmp_timestamp_regs *irqmp_ts =
>>  &GRLIB_IrqCtrl_Regs->timestamp[0];
>>
>> -if (!grlib_irqmp_has_timestamp(irqmp_ts)) {
>> +if (!irqmp_has_timestamp(irqmp_ts)) {
>>bsp_fatal(GRLIB_FATAL_CLOCK_NO_IRQMP_TIMESTAMP_SUPPORT);
>>  }
>>  #endif
>> diff --git a/bsps/shared/grlib/btimer/tlib_ckinit.c
>> b/bsps/shared/grlib/btimer/tlib_ckinit.c
>> index 4f679984d8..5a34d97c00 100644
>> --- a/bsps/shared/grlib/btimer/tlib_ckinit.c
>> +++ b/bsps/shared/grlib/btimer/tlib_ckinit.c
>> @@ -126,7 +126,7 @@ static rtems_device_driver tlib_clock_find_timer(void)
>>  volatile struct irqmp_timestamp_regs *irqmp_ts;
>>
>>  irqmp_ts = &LEON3_IrqCtrl_Regs->timestamp[0];
>> -if (leon3_irqmp_has_timestamp(irqmp_ts)) {
>> +if (irqmp_has_timestamp(irqmp_ts)) {
>>priv.ops = &ops_irqamp;
>>return RTEMS_SUCCESSFUL;
>>  }
>> diff --git a/bsps/sparc/leon3/clock/ckinit.c
>> b/bsps/sparc/leon3/clock/ckinit.c
>> index f485123f6b..bf0c506ec0 100644
>> --- a/bsps/sparc/leon3/clock/ckinit.c
>> +++ b/bsps/sparc/leon3/clock/ckinit.c
>> @@ -176,13 +176,13 @@ static void leon3_clock_initialize(void)
>>  tc->tc_frequency = leon3_up_counter_frequency();
>>
>>  #ifdef RTEMS_PROFILING
>> -if (!leon3_irqmp_has_timestamp(irqmp_ts)) {
>> +if (!irqmp_has_timestamp(irqmp_ts)) {
>>bsp_fatal(LEON3_FATAL_CLOCK_NO_IRQMP_TIMESTAMP_SUPPORT);
>>  }
>>  #endif
>>
>>  leon3_tc_tick = leon3_tc_tick_irqmp_timestamp_init;
>> -  } else if (leon3_irqmp_has_timestamp(irqmp_ts)) {
>> +  } else if (irqmp_has_timestamp(irqmp_ts)) {
>>  /* Use the interrupt controller timestamp counter if available */
>>  tc->tc_get_timecount = _SPARC_Get_timecount_up;
>>  tc->tc_frequency = ambapp_freq_get(&ambapp_plb, LEON3_Timer_Adev);
>> diff --git a/bsps/sparc/leon3/include/leon.h
>> b/bsps/sparc/leon3/include/leon.h
>> index afe0d91ca4..d25825c8e8 100644
>> --- a/bsps/sparc/leon3/include/leon.h
>> +++ b/bsps/sparc/leon3/include/leon.h
>> @@ -454,13 +454,6 @@ static inline uint32_t
>> leon3_get_data_cache_config_register(void)
>>return leon3_get_system_register(0xc);
>>  }
>>
>> -static inline bool leon3_irqmp_has_timestamp(
>> -  volatile struct irqmp_timestamp_regs *irqmp_ts
>> -)
>> -{
>> -  return (irqmp_ts->control >> 27) > 0;
>> -}
>> -
>>  static inline uint32_t leon3_up_counter_low(void)
>>  {
>>uint32_t asr23;
>> diff --git a/bsps/sparc/leon3/start/cpucounter.c
>> b/bsps/sparc/leon3/start/cpucounter.c
>> index 007bb6d8ec..1d96e3b221 100644
>> --- a/bsps/sparc/leon3/start/cpucounter.c
>> +++ b/bsps/sparc/leon3/start/cpucounter.c
>> @@ -43,7 +43,7 @@ static void leon3_counter_initialize(void)
>>  counter->read = _SPARC_Counter_read_asr23;
>>
>>  leon3_counter_frequency = leon3_up_counter_frequency();
>> -  } else if (leon3_irqmp_has_timestamp(irqmp_ts)) {
>> +  } else if (irqmp_has_timestamp(irqmp_ts))

Need help debugging sp16.exe

2020-10-08 Thread Richi Dubey 
Hi,

I have been trying to debug sp16 for the last few days. I am using the new
Strong APA scheduler we worked on during this GSoC. The scheduler fails
only for the following tests:

 sp02.exe
 sp16.exe
 sp30.exe
 sp31.exe
 sp37.exe
 sp42.exe
 spfatal29.exe
 tm24.exe

On executing sp16.exe, I get the following output:

*** BEGIN OF TEST SP 16 ***
*** TEST VERSION: 5.0.0.61ccb9c05dcd695114541960aa6bfc1315f30514-modified
*** TEST STATE: EXPECTED_PASS
*** TEST BUILD: RTEMS_NETWORKING RTEMS_POSIX_API RTEMS_SMP
*** TEST TOOLS: 7.5.0 20191114 (RTEMS 5, RSB 5 (0b7e87143b76), Newlib
fbaa096)
TA1 - rtems_region_ident - rnid => 32010001
TA1 - rtems_region_get_segment - wait on 1000 byte segment from region 2
TA1 - got segment from region 2 - 0x0040
TA1 - rtems_region_get_segment - wait on 3K segment from region 3
TA1 - got segment from region 3 - 0x0080
TA1 - rtems_region_get_segment - get 3080 byte segment from region 1 -
NO_WAIT
TA1 - got segment from region 1 - 0x0040
TA1 - rtems_task_wake_after - yield processor
TA2 - rtems_region_get_segment - wait on 2K segment from region 1
TA1 - rtems_region_return_segment - return segment to region 1 - 0x0040
TA1 - rtems_region_get_segment - wait 10 seconds for 3K segment from region
1
TA2 - got segment from region 1 - 0x0040
TA2 - rtems_region_return_segment - return segment to region 1 - 0x0040
TA2 - rtems_task_set_priority - make self highest priority task
TA2 - rtems_region_get_segment - wait on 3750 byte segment
TA1 - got segment from region 1 - 0x0040
TA1 - rtems_region_return_segment - return segment to region 2 - 0x0040
TA2 - got segment from region 2 - 0x0040
TA2 - rtems_region_return_segment - return segment to region 2 - 0x0040
TA2 - rtems_task_exit
TA1 - rtems_task_wake_after - yield processor
TA3 - rtems_region_get_segment - wait on 3750 byte segment from region 2
TA3 - got segment from region 2 - 0x0040
TA3 - rtems_region_get_segment - wait on 2K segment from region 3
TA1 - rtems_task_delete - delete TA3
TA1 - rtems_task_wake_after - yield processor
TA4 - rtems_region_get_segment - wait on 1.5K segment from region 1
TA5 - rtems_region_get_segment - wait on 1.5K segment from region 1
TA1 - rtems_region_return_segment - return segment to region 1 - 0x0040
TA1 - rtems_task_wake_after - yield processor
TA4 - got and returned 0x0040
TA5 - got and returned 0x06c0
TA1 - rtems_region_get_segment - wait 10 seconds for 3K segment from region
1
TA1 - got segment from region 1 - 0x0040
TA1 - rtems_task_wake_after - yield processor
TA4 - rtems_region_get_segment - wait on 3K segment from region 1
TA5 - rtems_region_get_segment - wait on 3K segment from region 1
TA1 - rtems_task_delete - delete TA4
TA1 - rtems_region_return_segment - return segment to region 1 - 0x0040
TA1 - rtems_task_wake_after - yield processor
TA5 - got segment from region 1 - 0x0040
TA5 - rtems_region_return_segment - return segment to region 1 - 0x0040
TA5 - rtems_task_exit

and it doesn't progress further from here. It gets stuck in some kind of
loop. While debugging with gdb, I realized the loop is:

Clock_isr (arg=0x0) at
/home/richi/quick-start/src/rtems/bsps/arm/include/../../shared/dev/clock/clockimpl.h:155
155  _Thread_Heir == _Thread_Executing && _Thread_Executing->is_idle
(gdb)
0x001042fa 155  _Thread_Heir == _Thread_Executing &&
_Thread_Executing->is_idle
(gdb)
0x001042fc 155  _Thread_Heir == _Thread_Executing &&
_Thread_Executing->is_idle
(gdb)
0x001042fe 155  _Thread_Heir == _Thread_Executing &&
_Thread_Executing->is_idle
(gdb)

0x00104302 155  _Thread_Heir == _Thread_Executing &&
_Thread_Executing->is_idle
(gdb)
0x00104304 155  _Thread_Heir == _Thread_Executing &&
_Thread_Executing->is_idle
(gdb)
0x00104306 155  _Thread_Heir == _Thread_Executing &&
_Thread_Executing->is_idle
(gdb)
0x0010430a 155  _Thread_Heir == _Thread_Executing &&
_Thread_Executing->is_idle
(gdb)
154while (
(gdb)
0x0010430e 154while (
(gdb)
155  _Thread_Heir == _Thread_Executing && _Thread_Executing->is_idle
(gdb)
0x00104314 155  _Thread_Heir == _Thread_Executing &&
_Thread_Executing->is_idle
(gdb)
0x00104316 155  _Thread_Heir == _Thread_Executing &&
_Thread_Executing->is_idle
(gdb)
0x00104318 155  _Thread_Heir == _Thread_Executing &&
_Thread_Executing->is_idle
(gdb)
0x0010431c 155  _Thread_Heir == _Thread_Executing &&
_Thread_Executing->is_idle
(gdb)
0x0010431e 155  _Thread_Heir == _Thread_Executing &&
_Thread_Executing->is_idle
(gdb)
0x00104322 155  _Thread_Heir == _Thread_Executing &&
_Thread_Executing->is_idle
(gdb)
0x00104324 155  _Thread_Heir == _Thread_Executing &&
_Thread_Executing->is_idle
(gdb)
159  _Timecounter_Acquire(&lock_context);
(gdb)
0x001042d2 159  _Timecounter_Acquire(&lock_context);
(gdb)
0x001042d4 159  _Timecounter_Acquire(&lock_context);
(gdb)
0x001042d8 159

Re: Re: RTEMS Network Stack and Managed Switch

2020-10-08 Thread Joel Sherrill 
You didn't reply to the entire list so I am adding it back.

You are using the legacy stack (cpukit/libnetworking) which is 20+ years
old and IPV4 only.

There could be a packet which the older stack doesn't like the format of.
Perhaps a number pushes something out of range.

Any possibility there is IPV6 on the network? I don't know how this stack
reacts to that.

Another simple thing to try is increasing the size of the stacks and
turning on the stack checker.

--joel

On Thu, Oct 8, 2020 at 10:39 AM  wrote:

> Hi Joel,
>
>
>
> We are using Gaisler’s rc7 release for RTEMS 5.1.  I don’t see libbsd in
> the map file at all, but not really sure how to tell.
>
>
>
> We do have an FPU and our tasks are all FP enabled.  Not sure on the
> network stack.
>
>
>
> *From:* users  *On Behalf Of *Joel Sherrill
> *Sent:* Thursday, October 8, 2020 11:29 AM
> *To:* Thomas Doerfler 
> *Cc:* rtems-us...@rtems.org 
> *Subject:* [EXTERNAL] Re: RTEMS Network Stack and Managed Switch
>
>
>
>
>
>
>
> On Thu, Oct 8, 2020 at 10:25 AM Thomas Doerfler <
> thomas.doerf...@imd-systems.de> wrote:
>
> Richard,
>
> what hardware/BSP are you running on?
>
>
>
> Thomas beat me on this. :)
>
>
>
> Also the RTEMS version and network stack (legacy vs libbsd).
>
>
> Just a shot in the dark: It seems the system crashes in arplookup -> ...
> -> svfprintf. Can it be that some networking routine tries to print a
> message with floating point, but the FPU is disabled for the
> corresponding task?
>
>
>
> Since I recall you are using a LEON, this is indeed a very likely culprit.
>
>
>
> The stack trace is a bit odd since nothing in libc would call
> _Internal_XXX.
>
>
>
> --joel
>
>
> wkr,
>
> Thomas.
>
> Am 08.10.20 um 17:15 schrieb richard.glos...@l3harris.com:
> > We have discovered a problem with the RTEMS network stack reaching the
> > RTEMS _Terminate function when the interfaces are attached to a managed
> > switch (in this case a Cisco 3560).
> >
> >
> >
> > This does not occur with direct connections or when attached to a layer
> > 2 unmanaged switch (NetGear or SMC).  Of course the 3560 puts out a lot
> > of traffic that a layer 2 switch does not (spanning tree, CDP etc….)
> >
> >
> >
> > So it seems the managed switch is putting out traffic that is bringing
> > RTEMS down.
> >
> >
> >
> > Has anyone seen this behavior?  Have you determined the root cause?
> >
> >
> >
> >
> >
> > I set a break point and caught the following backtrace:
> >
> >
> >
> >   #0   0x6006ec90   0x60200180   <_Terminate+0x4>
> >
> >   #1   0x6006ece0   0x602001e8   <_Internal_error+0x8>
> >
> >   #2   0x600da250   0x60200248   <_svfprintf_r+0x14>
> >
> >   #3   0x600d5810   0x60200420   
> >
> >   #4   0x60073bac   0x60200508   
> >
> >   #5   0x60073e70   0x60200580   
> >
> >   #6   0x60073b78   0x60200630   
> >
> >   #7   0x60076340   0x60200698   
> >
> >   #8   0x60076e34   0x60200710   
> >
> >   #9   0x6008861c   0x602007c0   
> >
> >   #10  0x60088164   0x60200828   
> >
> >   #11  0x6006d210   0x60200888   <_Thread_Entry_adaptor_numeric+0x8>
> >
> >   #12  0x6006c464   0x602008e8   <_Thread_Handler+0x60>
> >
> >   #13  0x6006c404   0x60200948   <_Thread_Handler+0>
> >
> >
> >
> >
> >
> > CONFIDENTIALITY NOTICE: This email and any attachments are for the sole
> > use of the intended recipient and may contain material that is
> > proprietary, confidential, privileged or otherwise legally protected or
> > restricted under applicable government laws. Any review, disclosure,
> > distributing or other use without expressed permission of the sender is
> > strictly prohibited. If you are not the intended recipient, please
> > contact the sender and delete all copies without reading, printing, or
> > saving.
> >
> >
> > ___
> > users mailing list
> > us...@rtems.org
> > http://lists.rtems.org/mailman/listinfo/users
> >
>
> --
> IMD Ingenieurbuero fuer Microcomputertechnik
> Thomas Doerfler   Herbststrasse 8
> D-82178 Puchheim  Germany
> email:thomas.doerf...@imd-systems.de
> PGP public key available on request
> ___
> users mailing list
> us...@rtems.org
> http://lists.rtems.org/mailman/listinfo/users
>
>
>
> CONFIDENTIALITY NOTICE: This email and any attachments are for the sole
> use of the intended recipient and may contain material that is proprietary,
> confidential, privileged or otherwise legally protected or restricted under
> applicable government laws. Any review, disclosure, distributing or other
> use without expressed permission of the sender is strictly prohibited. If
> you are not the intended recipient, please contact the sender and delete
> all copies without reading, printing, or saving.
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH v2] rtems: Generate

2020-10-08 Thread Gedare Bloom 
Hi Sebastian,


On Thu, Oct 8, 2020 at 12:35 AM Sebastian Huber
 wrote:
>
> The manager documentation is a consolidation of the comments in Doxygen
> markup and the documentation sources in Sphinx markup.  The
> documentation was transfered to interface specification items.  This
> header file was generated from the items by a script.
>
> Change license to BSD-2-Clause according to file histories and
> documentation re-licensing agreement.
>
> Update #3899.
> Update #3993.
> ---
> v2:
>
> * Fix some typos.
>
> Doxygen output can be reviewed here:
>
> https://ftp.rtems.org/pub/rtems/people/sebh/doc/html/group__RTEMSAPIClassicIO.html
>
This one looks good to me.

> https://ftp.rtems.org/pub/rtems/people/sebh/doc/html/group__RTEMSAPIClassicEvent.html

However, I was reviewing the doxygen output of event.h and see that it
generates the bitmask macros in a strange order. I think these need to
be fixed to keep them grouped and order them with respect to each
other in ascending/descending order. I guess this can be complex, but
it is needed for human readability in this case.

>
> https://ftp.rtems.org/pub/rtems/people/sebh/doc/html/group__RTEMSAPIClassicPart.html
>
>  cpukit/include/rtems/io.h | 499 --
>  1 file changed, 377 insertions(+), 122 deletions(-)
>
> diff --git a/cpukit/include/rtems/io.h b/cpukit/include/rtems/io.h
> index 67364df280..5fc984ed44 100644
> --- a/cpukit/include/rtems/io.h
> +++ b/cpukit/include/rtems/io.h
> @@ -1,228 +1,483 @@
> +/* SPDX-License-Identifier: BSD-2-Clause */
> +
>  /**
>   * @file
>   *
> - * @brief Classic Input/Output Manager API
> - *
> - * This file emulates the old Classic RTEMS IO manager directives
> - * which register names using the in-memory filesystem.
> + * @ingroup RTEMSAPIClassicIO
> + *
> + * @brief This header file defines the IO Manager API.
> + */
> +
> +/*
> + * Copyright (C) 2020 embedded brains GmbH (http://www.embedded-brains.de)
> + * Copyright (C) 1988, 2008 On-Line Applications Research Corporation (OAR)
> + *
> + * Redistribution and use in source and binary forms, with or without
> + * modification, are permitted provided that the following conditions
> + * are met:
> + * 1. Redistributions of source code must retain the above copyright
> + *notice, this list of conditions and the following disclaimer.
> + * 2. Redistributions in binary form must reproduce the above copyright
> + *notice, this list of conditions and the following disclaimer in the
> + *documentation and/or other materials provided with the distribution.
> + *
> + * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS 
> IS"
> + * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
> + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
> + * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE
> + * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
> + * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
> + * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
> + * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
> + * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
> + * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
> + * POSSIBILITY OF SUCH DAMAGE.
>   */
>
>  /*
> - *  COPYRIGHT (c) 1989-2008.
> - *  On-Line Applications Research Corporation (OAR).
> + * Do not manually edit this file.  It is part of the RTEMS quality process
> + * and was automatically generated.
> + *
> + * If you find something that needs to be fixed or worded better please
> + * post a report to an RTEMS mailing list or raise a bug report:
> + *
> + * https://docs.rtems.org/branches/master/user/support/bugs.html
> + *
> + * For information on updating and regenerating please refer to:
>   *
> - *  The license and distribution terms for this file may be
> - *  found in the file LICENSE in this distribution or at
> - *  http://www.rtems.org/license/LICENSE.
> + * https://docs.rtems.org/branches/master/eng/req/howto.html
>   */
>
> +/* Generated from spec:/rtems/io/if/header */
> +
>  #ifndef _RTEMS_IO_H
>  #define _RTEMS_IO_H
>
> +#include 
>  #include 
>
>  #ifdef __cplusplus
>  extern "C" {
>  #endif
>
> +/* Generated from spec:/rtems/io/if/group */
> +
>  /**
> - * @defgroup ClassicIO Input/Output
> + * @defgroup RTEMSAPIClassicIO I/O Manager
>   *
>   * @ingroup RTEMSAPIClassic
>   *
> + * @brief The Input/Output (I/O) Manager provides a well-defined mechanism 
> for
> + *   accessing device drivers and a structured methodology for organizing
> + *   device drivers.
>   */
> -/**@{**/
>
> -typedef uint32_t rtems_device_major_number;
> +/* Generated from spec:/rtems/io/if/device-minor-number */
>
> +/**
> + * @ingroup RTEMSAPIClassicIO
> + *
> + * @brief This integer type represents the minor number of devices.
> + *
> + * The minor number o

Re: [PATCH v2] rtems: Generate

2020-10-08 Thread Sebastian Huber 

On 08/10/2020 18:12, Gedare Bloom wrote:


https://ftp.rtems.org/pub/rtems/people/sebh/doc/html/group__RTEMSAPIClassicEvent.html

However, I was reviewing the doxygen output of event.h and see that it
generates the bitmask macros in a strange order. I think these need to
be fixed to keep them grouped and order them with respect to each
other in ascending/descending order. I guess this can be complex, but
it is needed for human readability in this case.

In the topological sorting items with more references are placed before 
items with fewer references. This explains the ordering in the header 
file. I have currently no idea how this can be changed.

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

Re: Need help debugging sp16.exe

2020-10-08 Thread Gedare Bloom 
On Thu, Oct 8, 2020 at 9:38 AM Richi Dubey  wrote:
>
> Hi,
>
> I have been trying to debug sp16 for the last few days. I am using the new 
> Strong APA scheduler we worked on during this GSoC. The scheduler fails only 
> for the following tests:
>
>  sp02.exe
>  sp16.exe
>  sp30.exe
>  sp31.exe
>  sp37.exe
>  sp42.exe
>  spfatal29.exe
>  tm24.exe
>
> On executing sp16.exe, I get the following output:
>
> *** BEGIN OF TEST SP 16 ***
> *** TEST VERSION: 5.0.0.61ccb9c05dcd695114541960aa6bfc1315f30514-modified
> *** TEST STATE: EXPECTED_PASS
> *** TEST BUILD: RTEMS_NETWORKING RTEMS_POSIX_API RTEMS_SMP
> *** TEST TOOLS: 7.5.0 20191114 (RTEMS 5, RSB 5 (0b7e87143b76), Newlib fbaa096)
> TA1 - rtems_region_ident - rnid => 32010001
> TA1 - rtems_region_get_segment - wait on 1000 byte segment from region 2
> TA1 - got segment from region 2 - 0x0040
> TA1 - rtems_region_get_segment - wait on 3K segment from region 3
> TA1 - got segment from region 3 - 0x0080
> TA1 - rtems_region_get_segment - get 3080 byte segment from region 1 - NO_WAIT
> TA1 - got segment from region 1 - 0x0040
> TA1 - rtems_task_wake_after - yield processor
> TA2 - rtems_region_get_segment - wait on 2K segment from region 1
> TA1 - rtems_region_return_segment - return segment to region 1 - 0x0040
> TA1 - rtems_region_get_segment - wait 10 seconds for 3K segment from region 1
> TA2 - got segment from region 1 - 0x0040
> TA2 - rtems_region_return_segment - return segment to region 1 - 0x0040
> TA2 - rtems_task_set_priority - make self highest priority task
> TA2 - rtems_region_get_segment - wait on 3750 byte segment
> TA1 - got segment from region 1 - 0x0040
> TA1 - rtems_region_return_segment - return segment to region 2 - 0x0040
> TA2 - got segment from region 2 - 0x0040
> TA2 - rtems_region_return_segment - return segment to region 2 - 0x0040
> TA2 - rtems_task_exit
> TA1 - rtems_task_wake_after - yield processor
> TA3 - rtems_region_get_segment - wait on 3750 byte segment from region 2
> TA3 - got segment from region 2 - 0x0040
> TA3 - rtems_region_get_segment - wait on 2K segment from region 3
> TA1 - rtems_task_delete - delete TA3
> TA1 - rtems_task_wake_after - yield processor
> TA4 - rtems_region_get_segment - wait on 1.5K segment from region 1
> TA5 - rtems_region_get_segment - wait on 1.5K segment from region 1
> TA1 - rtems_region_return_segment - return segment to region 1 - 0x0040
> TA1 - rtems_task_wake_after - yield processor
> TA4 - got and returned 0x0040
> TA5 - got and returned 0x06c0
> TA1 - rtems_region_get_segment - wait 10 seconds for 3K segment from region 1
> TA1 - got segment from region 1 - 0x0040
> TA1 - rtems_task_wake_after - yield processor
> TA4 - rtems_region_get_segment - wait on 3K segment from region 1
> TA5 - rtems_region_get_segment - wait on 3K segment from region 1
> TA1 - rtems_task_delete - delete TA4
> TA1 - rtems_region_return_segment - return segment to region 1 - 0x0040
> TA1 - rtems_task_wake_after - yield processor
> TA5 - got segment from region 1 - 0x0040
> TA5 - rtems_region_return_segment - return segment to region 1 - 0x0040
> TA5 - rtems_task_exit
>
> and it doesn't progress further from here. It gets stuck in some kind of 
> loop. While debugging with gdb, I realized the loop is:
>
> Clock_isr (arg=0x0) at 
> /home/richi/quick-start/src/rtems/bsps/arm/include/../../shared/dev/clock/clockimpl.h:155
> 155  _Thread_Heir == _Thread_Executing && _Thread_Executing->is_idle
> (gdb)
> 0x001042fa 155  _Thread_Heir == _Thread_Executing && 
> _Thread_Executing->is_idle
> (gdb)
> 0x001042fc 155  _Thread_Heir == _Thread_Executing && 
> _Thread_Executing->is_idle
> (gdb)
> 0x001042fe 155  _Thread_Heir == _Thread_Executing && 
> _Thread_Executing->is_idle
> (gdb)
>
> 0x00104302 155  _Thread_Heir == _Thread_Executing && 
> _Thread_Executing->is_idle
> (gdb)
> 0x00104304 155  _Thread_Heir == _Thread_Executing && 
> _Thread_Executing->is_idle
> (gdb)
> 0x00104306 155  _Thread_Heir == _Thread_Executing && 
> _Thread_Executing->is_idle
> (gdb)
> 0x0010430a 155  _Thread_Heir == _Thread_Executing && 
> _Thread_Executing->is_idle
> (gdb)
> 154while (
> (gdb)
> 0x0010430e 154while (
> (gdb)
> 155  _Thread_Heir == _Thread_Executing && _Thread_Executing->is_idle
> (gdb)
> 0x00104314 155  _Thread_Heir == _Thread_Executing && 
> _Thread_Executing->is_idle
> (gdb)
> 0x00104316 155  _Thread_Heir == _Thread_Executing && 
> _Thread_Executing->is_idle
> (gdb)
> 0x00104318 155  _Thread_Heir == _Thread_Executing && 
> _Thread_Executing->is_idle
> (gdb)
> 0x0010431c 155  _Thread_Heir == _Thread_Executing && 
> _Thread_Executing->is_idle
> (gdb)
> 0x0010431e 155  _Thread_Heir == _Thread_Executing && 
> _Thread_Executing->is_idle
> (gdb)
> 0x00104322 155  _Thread_Heir == _Thread_Executing && 
> _Thread_Executing->is_idle
> (gdb)

Re: [PATCH 1/2] librtemsc++: Add join() and detach() to the thread

2020-10-08 Thread Gedare Bloom 
On Thu, Oct 8, 2020 at 2:19 AM  wrote:
>
> From: Chris Johns 
>
> - Do not start threads detached
> ---
>  cpukit/include/rtems/thread.hpp |  4 
>  cpukit/librtemscxx/thread.cpp   | 22 ++
>  2 files changed, 22 insertions(+), 4 deletions(-)
>
> diff --git a/cpukit/include/rtems/thread.hpp b/cpukit/include/rtems/thread.hpp
> index e90e664dfa..2c4899dc0b 100644
> --- a/cpukit/include/rtems/thread.hpp
> +++ b/cpukit/include/rtems/thread.hpp
> @@ -321,6 +321,10 @@ namespace rtems
>
>bool joinable() const noexcept;
>
> +  void join() noexcept;
> +
> +  void detach() noexcept;
> +
>/*
> * Constrain use. These are not available.
> */
> diff --git a/cpukit/librtemscxx/thread.cpp b/cpukit/librtemscxx/thread.cpp
> index 11bf3df230..ae13201bd4 100644
> --- a/cpukit/librtemscxx/thread.cpp
> +++ b/cpukit/librtemscxx/thread.cpp
> @@ -346,6 +346,24 @@ namespace rtems
>return !(id_ == id());
>  }
>
> +void
> +thread::join() noexcept
> +{
> +  if (!joinable())
explicit { for 1-liners is preferred
> +system_error_check (ENOMEM, "join");
}

In general, this file is not entirely adhering to RTEMS coding style.
What coding style is it? Sorry I missed this in the first patch(es)
adding the cxx iface

> +  system_error_check (::pthread_join (id_.id_, nullptr), "join");
prefer to not have a space before the ( for function calls so that
function-like macros appear consistently

> +  id_ = id();
> +}
> +
> +void
> +thread::detach() noexcept
> +{
> +  if (!joinable())
> +system_error_check (EINVAL, "detach");
> +  system_error_check (::pthread_detach (id_.id_), "detach");
> +  id_ = id();
> +}
> +
>  thread::state_base::~state_base () = default;
>
>  void
> @@ -358,10 +376,6 @@ namespace rtems
>system_error_check (::pthread_attr_init (&pattr),
>"attribute init");
>
> -  system_error_check (::pthread_attr_setdetachstate (&pattr,
> - 
> PTHREAD_CREATE_DETACHED),
> -  "set detached state");
> -
>struct sched_param param;
>param.sched_priority = attr.get_priority ();
>system_error_check (::pthread_attr_setschedparam (&pattr, ¶m),
> --
> 2.24.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

[PATCH] 4.11 source-builder/config/gcc*.cfg: Update location of MPC

2020-10-08 Thread Joel Sherrill 
MPC should be fetched from ftp.gnu.org

Closes #4132.
---
 source-builder/config/gcc-4.3-1.cfg | 2 +-
 source-builder/config/gcc-4.4-1.cfg | 2 +-
 source-builder/config/gcc-4.5-1.cfg | 2 +-
 source-builder/config/gcc-4.6-1.cfg | 2 +-
 source-builder/config/gcc-4.8-1.cfg | 2 +-
 source-builder/config/gcc-4.9-1.cfg | 2 +-
 6 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/source-builder/config/gcc-4.3-1.cfg 
b/source-builder/config/gcc-4.3-1.cfg
index 69ea367..b344134 100644
--- a/source-builder/config/gcc-4.3-1.cfg
+++ b/source-builder/config/gcc-4.3-1.cfg
@@ -27,7 +27,7 @@
 # Packages GCC requires
 #
 %source set mpfr 
http://www.mpfr.org/mpfr-%{mpfr_version}/mpfr-%{mpfr_version}.tar.bz2
-%source set mpc 
http://www.multiprecision.org/mpc/download/mpc-%{mpc_version}.tar.gz
+%source set mpc https://ftp.gnu.org/gnu/mpc/mpc-%{mpc_version}.tar.gz
 %source set gmp https://ftp.gnu.org/gnu/gmp/gmp-%{gmp_version}.tar.bz2
 
 #
diff --git a/source-builder/config/gcc-4.4-1.cfg 
b/source-builder/config/gcc-4.4-1.cfg
index 2c70919..433185f 100644
--- a/source-builder/config/gcc-4.4-1.cfg
+++ b/source-builder/config/gcc-4.4-1.cfg
@@ -26,7 +26,7 @@
 # Packages GCC requires
 #
 %source set mpfr 
http://www.mpfr.org/mpfr-%{mpfr_version}/mpfr-%{mpfr_version}.tar.bz2
-%source set mpc 
http://www.multiprecision.org/mpc/download/mpc-%{mpc_version}.tar.gz
+%source set mpc https://ftp.gnu.org/gnu/mpc/mpc-%{mpc_version}.tar.gz
 %source set gmp https://ftp.gnu.org/gnu/gmp/gmp-%{gmp_version}.tar.bz2
 
 #
diff --git a/source-builder/config/gcc-4.5-1.cfg 
b/source-builder/config/gcc-4.5-1.cfg
index fbff31c..93953fa 100644
--- a/source-builder/config/gcc-4.5-1.cfg
+++ b/source-builder/config/gcc-4.5-1.cfg
@@ -22,7 +22,7 @@
 # Packages GCC requires
 #
 %source set mpfr 
http://www.mpfr.org/mpfr-%{mpfr_version}/mpfr-%{mpfr_version}.tar.bz2
-%source set mpc 
http://www.multiprecision.org/mpc/download/mpc-%{mpc_version}.tar.gz
+%source set mpc https://ftp.gnu.org/gnu/mpc/mpc-%{mpc_version}.tar.gz
 %source set gmp https://ftp.gnu.org/gnu/gmp/gmp-%{gmp_version}.tar.bz2
 
 #
diff --git a/source-builder/config/gcc-4.6-1.cfg 
b/source-builder/config/gcc-4.6-1.cfg
index 98f8d7e..6d49b6d 100644
--- a/source-builder/config/gcc-4.6-1.cfg
+++ b/source-builder/config/gcc-4.6-1.cfg
@@ -26,7 +26,7 @@
 # Packages GCC requires
 #
 %source set mpfr 
http://www.mpfr.org/mpfr-%{mpfr_version}/mpfr-%{mpfr_version}.tar.bz2
-%source set mpc 
http://www.multiprecision.org/mpc/download/mpc-%{mpc_version}.tar.gz
+%source set mpc https://ftp.gnu.org/gnu/mpc/mpc-%{mpc_version}.tar.gz
 %source set gmp https://ftp.gnu.org/gnu/gmp/gmp-%{gmp_version}.tar.bz2
 
 #
diff --git a/source-builder/config/gcc-4.8-1.cfg 
b/source-builder/config/gcc-4.8-1.cfg
index aa62837..8ed427f 100644
--- a/source-builder/config/gcc-4.8-1.cfg
+++ b/source-builder/config/gcc-4.8-1.cfg
@@ -22,7 +22,7 @@
 # Packages GCC requires
 #
 %source set mpfr 
http://www.mpfr.org/mpfr-%{mpfr_version}/mpfr-%{mpfr_version}.tar.bz2
-%source set mpc 
http://www.multiprecision.org/downloads/mpc-%{mpc_version}.tar.gz
+%source set mpc https://ftp.gnu.org/gnu/mpc/mpc-%{mpc_version}.tar.gz
 %source set gmp https://ftp.gnu.org/gnu/gmp/gmp-%{gmp_version}.tar.bz2
 
 #
diff --git a/source-builder/config/gcc-4.9-1.cfg 
b/source-builder/config/gcc-4.9-1.cfg
index 25e4247..8821c7c 100644
--- a/source-builder/config/gcc-4.9-1.cfg
+++ b/source-builder/config/gcc-4.9-1.cfg
@@ -22,7 +22,7 @@
 # Packages GCC requires
 #
 %source set mpfr 
http://www.mpfr.org/mpfr-%{mpfr_version}/mpfr-%{mpfr_version}.tar.bz2
-%source set mpc 
http://www.multiprecision.org/mpc/download/mpc-%{mpc_version}.tar.gz
+%source set mpc https://ftp.gnu.org/gnu/mpc/mpc-%{mpc_version}.tar.gz
 %source set gmp https://ftp.gnu.org/gnu/gmp/gmp-%{gmp_version}.tar.bz2
 
 #
-- 
2.24.3

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

Re: [PATCH v2] rtems: Generate

2020-10-08 Thread Peter Dufault 
I have a minor issue with the ordering. *I haven't looked too much through 
earlier documents.*

I don't think this has anything to do with Sebastians work, but I think it is 
odd that "close" comes before directives like "I/O control" (or whatever it's 
called) that need to be invoked when the interface is open. If the ordering is 
intended to correspond to normal usage, as I think Joel said, this is wrong and 
"close" should be at the end.

If that's how the current documentation is structured we should stick with it 
and change it later.

> On Oct 8, 2020, at 02:18 , Sebastian Huber 
>  wrote:
> 
> On 07/10/2020 21:12, Gedare Bloom wrote:
> 
>> On Wed, Oct 7, 2020 at 11:40 AM Sebastian Huber
>>  wrote:
>>> On 07/10/2020 17:26, Gedare Bloom wrote:
>>> 
 Thinking about the discussion about ordering directives in the docs,
 the generated header reorders directives also. Is it also doing
 generation by alphabetical order?
 
 Should we consider using the same order as defined for the API
 documentation? I guess this would make the Doxygen consistently
 ordered wrt the docs.
>>> This would make things a lot more complicated. For the Doxygen we have
>>> to take also the C language into account. For example before you use a
>>> type, it must be declared. This is done through automatic dependency
>>> tracking and a topological sorting. Adding a manual order into this
>>> stuff would be difficult.
>> Yeah, maybe. The value of ordering in the headers and doxygen is
>> probably less than in a manual. We can revisit later if we like. It
>> shouldn't be too hard in an API header (as opposed to an
>> implementation header with inlines) to group first the typedefs and
>> then the function declarations. But I have no real concern about the
>> ordering here, it was just a thought.
> 
> Good, I added a ticket for this:
> 
> https://devel.rtems.org/ticket/4134#ticket
> 
> It is not on my high priority list.
> 
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel

Peter
-
Peter Dufault
HD Associates, Inc.  Software and System Engineering

This email is delivered through the public internet using protocols subject to 
interception and tampering.



signature.asc
Description: Message signed with OpenPGP
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH v2] rtems: Generate

2020-10-08 Thread Gedare Bloom 
On Thu, Oct 8, 2020 at 12:51 PM Peter Dufault  wrote:
>
> I have a minor issue with the ordering. *I haven't looked too much through 
> earlier documents.*
>
> I don't think this has anything to do with Sebastians work, but I think it is 
> odd that "close" comes before directives like "I/O control" (or whatever it's 
> called) that need to be invoked when the interface is open. If the ordering 
> is intended to correspond to normal usage, as I think Joel said, this is 
> wrong and "close" should be at the end.
>
> If that's how the current documentation is structured we should stick with it 
> and change it later.
>
Hi Peter,

You're right, and Sebastian has fixed it for the RTEMS Manuals.
However, this is for the generated doxygen. It is also manifesting
this seemingly arbitrary ordering in the DOxygen because of the
ordering in how different items get generated while creating the
header files.

I would like to understand how hard this might be to rectify, and
whether it is something we can defer or if we accept this as-is if it
is likely to stay mixed-up and confusing forever.

Gedare

> > On Oct 8, 2020, at 02:18 , Sebastian Huber 
> >  wrote:
> >
> > On 07/10/2020 21:12, Gedare Bloom wrote:
> >
> >> On Wed, Oct 7, 2020 at 11:40 AM Sebastian Huber
> >>  wrote:
> >>> On 07/10/2020 17:26, Gedare Bloom wrote:
> >>>
>  Thinking about the discussion about ordering directives in the docs,
>  the generated header reorders directives also. Is it also doing
>  generation by alphabetical order?
> 
>  Should we consider using the same order as defined for the API
>  documentation? I guess this would make the Doxygen consistently
>  ordered wrt the docs.
> >>> This would make things a lot more complicated. For the Doxygen we have
> >>> to take also the C language into account. For example before you use a
> >>> type, it must be declared. This is done through automatic dependency
> >>> tracking and a topological sorting. Adding a manual order into this
> >>> stuff would be difficult.
> >> Yeah, maybe. The value of ordering in the headers and doxygen is
> >> probably less than in a manual. We can revisit later if we like. It
> >> shouldn't be too hard in an API header (as opposed to an
> >> implementation header with inlines) to group first the typedefs and
> >> then the function declarations. But I have no real concern about the
> >> ordering here, it was just a thought.
> >
> > Good, I added a ticket for this:
> >
> > https://devel.rtems.org/ticket/4134#ticket
> >
> > It is not on my high priority list.
> >
> > ___
> > devel mailing list
> > devel@rtems.org
> > http://lists.rtems.org/mailman/listinfo/devel
>
> Peter
> -
> Peter Dufault
> HD Associates, Inc.  Software and System Engineering
>
> This email is delivered through the public internet using protocols subject 
> to interception and tampering.
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Building libbsd after installing libbsd

2020-10-08 Thread Joel Sherrill 
Hi

I am not sure if this is avoidable but it is surprising.

+ build and install rtems to $prefix

+ build and install libbsd to $prefix

+ ./waf will then rebuild some files. It appears to be using installed
headers

+ Then ./waf install and it will also rebuild some files before fails.

I think there is no way to avoid this and waf for libbsd should detect that
it sees headers installed from itself and give an error that you need a
clean $prefix to build.

Just to make sure there wasn't interference between two different BSPs, I
built and installed one followed by a second different one. That went fine.

The behavior is bizarre and the weird compilation errors are mysterious
until you repeat the steps enough to figure it out. Unless someone knows
how the build can avoid this, I think we need an error check early in the
configure process.

I think it is sufficient to check if machine/rtems-bsd-nexus-bus.h is
installed already ad give a nice explanation and failure during configure.

Thoughts?

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

Re: Documentation image source

2020-10-08 Thread Chris Johns 
On 8/10/20 11:34 pm, Joel Sherrill wrote:
> Dot can produce svg
> 
> dot -Tsvg graph.dot -o file
> 
> PlantUML appears to use -tsvg
> 
> Does that help?

I do not know. Can sphinx accept svg images and have them render in HTML and
PDF? It would be a nice solution if it did.

On the subject of the commands to be used can we please document the packages
used in the README.txt and teach waf to check for the package and build the
images when given a specific configure command line option? We do not rebuild
the often and rarely replace them but it is important to be able to do this to
make sure the tools we depend on have not changed. We should capture this stuff
and not expect someone who trips over an issue to have to figure out what was
used and how it was used.

So could dot files please be documented and added to waf? :)

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

Re: Building libbsd after installing libbsd

2020-10-08 Thread Chris Johns 
On 9/10/20 8:24 am, Joel Sherrill wrote:
> Hi
> 
> I am not sure if this is avoidable but it is surprising. 
> 
> + build and install rtems to $prefix
> 
> + build and install libbsd to $prefix
> 
> + ./waf will then rebuild some files. It appears to be using installed headers

Is this in rtems or libbsd?

> + Then ./waf install and it will also rebuild some files before fails.

Again which or is it both?

> I think there is no way to avoid this and waf for libbsd should detect that it
> sees headers installed from itself and give an error that you need a clean
> $prefix to build.

Waf uses an md5 checksum for dependency checking so replacing a file with the
same file should not trigger a rebuild, the contents have to have changed. This
is different to make and others that stat a file.

> Just to make sure there wasn't interference between two different BSPs, I 
> built
> and installed one followed by a second different one. That went fine. 
> 
> The behavior is bizarre and the weird compilation errors are mysterious until
> you repeat the steps enough to figure it out. Unless someone knows how the 
> build
> can avoid this, I think we need an error check early in the configure 
> process. 

This implies some files in one package are overwriting a file installed by
another package. That should not happen.

It would be nice to install a manifesto of the files a package installs. I am
sure it would aid deployment for those wanting to package and deploy RTEMS with
rpm, deb or what ever else. It would help here as the contents of each could be
reviewed.

> I think it is sufficient to check if machine/rtems-bsd-nexus-bus.h is 
> installed
> already ad give a nice explanation and failure during configure.

Adding this would limit those develop and maintaining these packages.

> Thoughts?

Should we understand the interactions before we decide on a solution?

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

Re: Building libbsd after installing libbsd

2020-10-08 Thread Joel Sherrill 
On Thu, Oct 8, 2020 at 4:59 PM Chris Johns  wrote:

> On 9/10/20 8:24 am, Joel Sherrill wrote:
> > Hi
> >
> > I am not sure if this is avoidable but it is surprising.
> >
> > + build and install rtems to $prefix
> >
> > + build and install libbsd to $prefix
> >
> > + ./waf will then rebuild some files. It appears to be using installed
> headers
>
> Is this in rtems or libbsd?
>

libbsd. RTEMS can be install and then "./waf" does nothing like you would
expect.

>
> > + Then ./waf install and it will also rebuild some files before fails.
>
> Again which or is it both?
>

libbsd only

>
> > I think there is no way to avoid this and waf for libbsd should detect
> that it
> > sees headers installed from itself and give an error that you need a
> clean
> > $prefix to build.
>
> Waf uses an md5 checksum for dependency checking so replacing a file with
> the
> same file should not trigger a rebuild, the contents have to have changed.
> This
> is different to make and others that stat a file.
>

Then something is confusing it. The first build is with the file in the
libbsd tree. Running
waf again, I think it is using the installed one.

>
> > Just to make sure there wasn't interference between two different BSPs,
> I built
> > and installed one followed by a second different one. That went fine.
> >
> > The behavior is bizarre and the weird compilation errors are mysterious
> until
> > you repeat the steps enough to figure it out. Unless someone knows how
> the build
> > can avoid this, I think we need an error check early in the configure
> process.
>
> This implies some files in one package are overwriting a file installed by
> another package. That should not happen.
>
> It would be nice to install a manifesto of the files a package installs. I
> am
> sure it would aid deployment for those wanting to package and deploy RTEMS
> with
> rpm, deb or what ever else. It would help here as the contents of each
> could be
> reviewed.
>
It would be nice but I don't think that solves this.

>
> > I think it is sufficient to check if machine/rtems-bsd-nexus-bus.h is
> installed
> > already ad give a nice explanation and failure during configure.
>
> Adding this would limit those develop and maintaining these packages.
>

The behavior now seems to confuse in-tree and installed header files is my
guess.


>
> > Thoughts?
>
> Should we understand the interactions before we decide on a solution?
>

Sure. If there really is an avoidable bug.

--joel

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

Re: [PATCH 1/2] librtemsc++: Add join() and detach() to the thread

2020-10-08 Thread Chris Johns 
On 9/10/20 3:28 am, Gedare Bloom wrote:
> On Thu, Oct 8, 2020 at 2:19 AM  wrote:
>>
>> From: Chris Johns 
>>
>> - Do not start threads detached
>> ---
>>  cpukit/include/rtems/thread.hpp |  4 
>>  cpukit/librtemscxx/thread.cpp   | 22 ++
>>  2 files changed, 22 insertions(+), 4 deletions(-)
>>
>> diff --git a/cpukit/include/rtems/thread.hpp 
>> b/cpukit/include/rtems/thread.hpp
>> index e90e664dfa..2c4899dc0b 100644
>> --- a/cpukit/include/rtems/thread.hpp
>> +++ b/cpukit/include/rtems/thread.hpp
>> @@ -321,6 +321,10 @@ namespace rtems
>>
>>bool joinable() const noexcept;
>>
>> +  void join() noexcept;
>> +
>> +  void detach() noexcept;

Hmmm I the `noexcept` is wrong here as an exception may be raised. I will remove
these.

>> +
>>/*
>> * Constrain use. These are not available.
>> */
>> diff --git a/cpukit/librtemscxx/thread.cpp b/cpukit/librtemscxx/thread.cpp
>> index 11bf3df230..ae13201bd4 100644
>> --- a/cpukit/librtemscxx/thread.cpp
>> +++ b/cpukit/librtemscxx/thread.cpp
>> @@ -346,6 +346,24 @@ namespace rtems
>>return !(id_ == id());
>>  }
>>
>> +void
>> +thread::join() noexcept
>> +{
>> +  if (!joinable())
> explicit { for 1-liners is preferred

Yes ... old habits ...

>> +system_error_check (ENOMEM, "join");
> }
> 
> In general, this file is not entirely adhering to RTEMS coding style.
> What coding style is it? Sorry I missed this in the first patch(es)
> adding the cxx iface

It does not entirely follow the coding style as it is C++.

The code was first posted in December 2019 and goes back further as I played.
The C++ makes use of advanced template techniques, nesting classes and structs,
namespace, exceptions and more. Some of the coding standard is fine and other
parts do not work and do not relate. I have not checked in detail.

>> +  system_error_check (::pthread_join (id_.id_, nullptr), "join");
> prefer to not have a space before the ( for function calls so that
> function-like macros appear consistently

Interesting, this is something the GNU coding standard recommends as being more
readable [1]. I did not know it was a requirement in the coding standard. I am
not fused and can fix this but it would take a little time so let me know what
you would like me to do? Also if you have other places that need attention
please let me know.

Thanks
Chris

[1] https://www.gnu.org/prep/standards/html_node/Formatting.html#Formatting
 It is interesting how we directly conflict with some of what it says
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] 4.11 source-builder/config/gcc*.cfg: Update location of MPC

2020-10-08 Thread Chris Johns 
On 9/10/20 5:36 am, Joel Sherrill wrote:
>   MPC should be fetched from ftp.gnu.org
> 
> Closes #4132.

Please push. Thank you for the patch and the testing.

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

[PATCH v2 1/3] librtemscxx: Add join() and detach() to the thread

2020-10-08 Thread chrisj 
From: Chris Johns 

- Do not start threads detached
---
 cpukit/include/rtems/thread.hpp |  4 +++
 cpukit/librtemscxx/error.cpp|  9 ---
 cpukit/librtemscxx/thread.cpp   | 44 -
 3 files changed, 43 insertions(+), 14 deletions(-)

diff --git a/cpukit/include/rtems/thread.hpp b/cpukit/include/rtems/thread.hpp
index e90e664dfa..fb408f60c0 100644
--- a/cpukit/include/rtems/thread.hpp
+++ b/cpukit/include/rtems/thread.hpp
@@ -321,6 +321,10 @@ namespace rtems
 
   bool joinable() const noexcept;
 
+  void join();
+
+  void detach();
+
   /*
* Constrain use. These are not available.
*/
diff --git a/cpukit/librtemscxx/error.cpp b/cpukit/librtemscxx/error.cpp
index ba46a8c2a5..8723856ac9 100644
--- a/cpukit/librtemscxx/error.cpp
+++ b/cpukit/librtemscxx/error.cpp
@@ -56,21 +56,24 @@ namespace rtems
   void
   runtime_error_check (const rtems_status_code sc)
   {
-if (sc != RTEMS_SUCCESSFUL)
+if (sc != RTEMS_SUCCESSFUL) {
   throw runtime_error (sc);
+}
   }
 
   void
   runtime_error_check (const rtems_status_code sc, const std::string& what)
   {
-if (sc != RTEMS_SUCCESSFUL)
+if (sc != RTEMS_SUCCESSFUL) {
   throw runtime_error (sc, what);
+}
   }
 
   void
   runtime_error_check (const rtems_status_code sc, const char* what)
   {
-if (sc != RTEMS_SUCCESSFUL)
+if (sc != RTEMS_SUCCESSFUL) {
   throw runtime_error (sc, what);
+}
   }
 };
diff --git a/cpukit/librtemscxx/thread.cpp b/cpukit/librtemscxx/thread.cpp
index 11bf3df230..7ef9d6ac30 100644
--- a/cpukit/librtemscxx/thread.cpp
+++ b/cpukit/librtemscxx/thread.cpp
@@ -60,8 +60,9 @@ namespace rtems
 void
 system_error_check (int ec, const char* what)
 {
-  if (ec != 0)
+  if (ec != 0) {
 throw std::system_error (ec, std::system_category(), what);
+  }
 }
 
 attributes::attributes ()
@@ -206,8 +207,9 @@ namespace rtems
   if (!scheduler.empty ()) {
 char sname[4] = { ' ', ' ', ' ', ' ' };
 for (size_t c = 0; c < sizeof (sname); ++c) {
-  if (c >= scheduler.length ())
+  if (c >= scheduler.length ()) {
 break;
+  }
   sname[c] = scheduler[c];
 }
 rtems_name scheduler_name = rtems_build_name (sname[0],
@@ -285,8 +287,9 @@ namespace rtems
   runtime_error_check (::rtems_task_get_scheduler (RTEMS_SELF, 
&scheduler_id));
 #if HAVE_GET_SCHEDULER_NAME
   char name[5];
-  if (!get_scheduler_name (scheduler_id, &name[0]))
+  if (!get_scheduler_name (scheduler_id, &name[0])) {
 system_error_check (ENOENT, "get scheduler name");
+  }
   scheduler = name;
 #endif
 }
@@ -328,8 +331,9 @@ namespace rtems
 thread&
 thread::operator= (thread&& thread_)
 {
-  if (joinable ())
+  if (joinable ()) {
 std::terminate ();
+  }
   swap(thread_);
   return *this;
 }
@@ -346,6 +350,26 @@ namespace rtems
   return !(id_ == id());
 }
 
+void
+thread::join()
+{
+  if (!joinable()) {
+system_error_check (EINVAL, "join");
+  }
+  system_error_check (::pthread_join (id_.id_, nullptr), "join");
+  id_ = id();
+}
+
+void
+thread::detach()
+{
+  if (!joinable()) {
+system_error_check (EINVAL, "detach");
+  }
+  system_error_check (::pthread_detach (id_.id_), "detach");
+  id_ = id();
+}
+
 thread::state_base::~state_base () = default;
 
 void
@@ -358,14 +382,10 @@ namespace rtems
   system_error_check (::pthread_attr_init (&pattr),
   "attribute init");
 
-  system_error_check (::pthread_attr_setdetachstate (&pattr,
- 
PTHREAD_CREATE_DETACHED),
-  "set detached state");
-
   struct sched_param param;
   param.sched_priority = attr.get_priority ();
   system_error_check (::pthread_attr_setschedparam (&pattr, ¶m),
-  "set ");
+  "set sched param");
 
   int spolicy;
   switch (attr.get_scheduler_policy ()) {
@@ -385,10 +405,12 @@ namespace rtems
   system_error_check (::pthread_attr_setschedpolicy (&pattr, spolicy),
   "set scheduler policy");
 
-  if (attr.get_scheduler_attr () == attributes::sched_inherit)
+  if (attr.get_scheduler_attr () == attributes::sched_inherit) {
 ::pthread_attr_setinheritsched (&pattr, PTHREAD_INHERIT_SCHED);
-  else
+  }
+  else {
 ::pthread_attr_setinheritsched (&pattr, PTHREAD_EXPLICIT_SCHED);
+  }
 
   system_error_check (::pthread_attr_setstacksize(&pattr,
   attr.get_stack_size ()),
-- 
2.24.1

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

[PATCH v2 3/3] testsuite/rcxx01: Add examples for use in the User manual

2020-10-08 Thread chrisj 
From: Chris Johns 

---
 spec/build/testsuites/libtests/rcxx01.yml |   3 +
 testsuites/libtests/rcxx01/init.c |   2 +-
 testsuites/libtests/rcxx01/thread.cpp |  21 +++-
 testsuites/libtests/rcxx01/user-example-1.cpp |  49 
 testsuites/libtests/rcxx01/user-example-2.cpp |  68 +++
 testsuites/libtests/rcxx01/user-example-3.cpp | 113 ++
 6 files changed, 251 insertions(+), 5 deletions(-)
 create mode 100644 testsuites/libtests/rcxx01/user-example-1.cpp
 create mode 100644 testsuites/libtests/rcxx01/user-example-2.cpp
 create mode 100644 testsuites/libtests/rcxx01/user-example-3.cpp

diff --git a/spec/build/testsuites/libtests/rcxx01.yml 
b/spec/build/testsuites/libtests/rcxx01.yml
index 864ad4d9d6..49bd9cff66 100644
--- a/spec/build/testsuites/libtests/rcxx01.yml
+++ b/spec/build/testsuites/libtests/rcxx01.yml
@@ -13,6 +13,9 @@ links: []
 source:
 - testsuites/libtests/rcxx01/init.c
 - testsuites/libtests/rcxx01/thread.cpp
+- testsuites/libtests/rcxx01/user-example-1.cpp
+- testsuites/libtests/rcxx01/user-example-2.cpp
+- testsuites/libtests/rcxx01/user-example-3.cpp
 stlib: []
 target: testsuites/libtests/rcxx01.exe
 type: build
diff --git a/testsuites/libtests/rcxx01/init.c 
b/testsuites/libtests/rcxx01/init.c
index 87d3155c7f..bea71d14c7 100644
--- a/testsuites/libtests/rcxx01/init.c
+++ b/testsuites/libtests/rcxx01/init.c
@@ -72,7 +72,7 @@ rtems_task Init(
 #define CONFIGURE_MEMORY_OVERHEAD (2024)
 
 #define CONFIGURE_MAXIMUM_TASKS  1
-#define CONFIGURE_MAXIMUM_POSIX_THREADS 2
+#define CONFIGURE_MAXIMUM_POSIX_THREADS 5
 
 #define CONFIGURE_INITIAL_EXTENSIONS RTEMS_TEST_INITIAL_EXTENSION
 
diff --git a/testsuites/libtests/rcxx01/thread.cpp 
b/testsuites/libtests/rcxx01/thread.cpp
index 05a9de8c48..f977a340a9 100644
--- a/testsuites/libtests/rcxx01/thread.cpp
+++ b/testsuites/libtests/rcxx01/thread.cpp
@@ -36,6 +36,10 @@ using namespace std::chrono_literals;
 
 extern "C" void rcxx_run_test(void);
 
+void example_1();
+void example_2();
+void example_3();
+
 struct test_thread
 {
   test_thread();
@@ -96,13 +100,22 @@ bool test_thread::running()
   return finished == false;
 }
 
+void test_1()
+{
+  test_thread tt;
+  tt.start();
+  while (tt.running())
+std::this_thread::sleep_for(1s);
+}
+
 void rcxx_run_test(void)
 {
   try {
-test_thread tt;
-tt.start();
-while (tt.running())
-  std::this_thread::sleep_for(1s);
+test_1();
+/* From the user manual */
+example_1();
+example_2();
+example_3();
   } catch (...) {
 std::cout << "Thread: ouch" << std::endl;
 throw;
diff --git a/testsuites/libtests/rcxx01/user-example-1.cpp 
b/testsuites/libtests/rcxx01/user-example-1.cpp
new file mode 100644
index 00..dfc0992193
--- /dev/null
+++ b/testsuites/libtests/rcxx01/user-example-1.cpp
@@ -0,0 +1,49 @@
+/* SPDX-License-Identifier: BSD-2-Clause */
+
+/*
+ * Copyright (C) 2020 Chris Johns (http://contemporary.software)
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in the
+ *documentation and/or other materials provided with the distribution.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
+ * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE
+ * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
+ * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
+ * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
+ * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
+ * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
+ * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
+ * POSSIBILITY OF SUCH DAMAGE.
+ */
+
+#include 
+#include 
+
+#include 
+
+static void wait_for(size_t seconds)
+{
+  while (seconds--) {
+std::this_thread::sleep_for(std::chrono::seconds(1));
+std::cout << "Seconds: " << seconds << std::endl;
+  }
+}
+
+void example_1()
+{
+  std::cout << "Start example 1" << std::endl;
+
+  rtems::thread::thread t(wait_for, 5);
+  t.join();
+
+  std::cout << "End example 1" << std::endl;
+}
diff --git a/testsuites/libtests/rcxx01/user-example-2.cpp 
b/testsuites/libtests/rcxx01/user-example-2.cpp
new file mode 100644
index 00..05090fc73c
--- /dev/null
+++ b/testsuites/libtests/rcxx01/user-example-2.cpp
@@ -0,0 +1,68 @@
+/* SPDX-License-Identifier: BSD-2-Clause */
+
+/*
+ * C

[PATCH v2 2/3] librtemscxx: Fix white space to match the coding standard

2020-10-08 Thread chrisj 
From: Chris Johns 

---
 cpukit/include/rtems/error.hpp  |  14 +-
 cpukit/include/rtems/thread.hpp | 144 ++--
 cpukit/librtemscxx/error.cpp|  34 ++---
 cpukit/librtemscxx/thread.cpp   | 224 
 4 files changed, 208 insertions(+), 208 deletions(-)

diff --git a/cpukit/include/rtems/error.hpp b/cpukit/include/rtems/error.hpp
index a62ee966c6..cb705826d4 100644
--- a/cpukit/include/rtems/error.hpp
+++ b/cpukit/include/rtems/error.hpp
@@ -50,19 +50,19 @@ namespace rtems
   {
 const rtems_status_code sc;
   public:
-runtime_error (const rtems_status_code sc);
-runtime_error (const rtems_status_code sc, const std::string& what);
-runtime_error (const rtems_status_code sc, const char* what);
-~runtime_error ();
+runtime_error(const rtems_status_code sc);
+runtime_error(const rtems_status_code sc, const std::string& what);
+runtime_error(const rtems_status_code sc, const char* what);
+~runtime_error();
   };
 
   /**
* Throw a rtems::runtime_error exception if the RTEMS status code is
* not RTEMS_SUCCESSFUL.
*/
-  void runtime_error_check (const rtems_status_code sc);
-  void runtime_error_check (const rtems_status_code sc, const std::string& 
what);
-  void runtime_error_check (const rtems_status_code sc, const char* what);
+  void runtime_error_check(const rtems_status_code sc);
+  void runtime_error_check(const rtems_status_code sc, const std::string& 
what);
+  void runtime_error_check(const rtems_status_code sc, const char* what);
 };
 
 #endif
diff --git a/cpukit/include/rtems/thread.hpp b/cpukit/include/rtems/thread.hpp
index fb408f60c0..cdef690740 100644
--- a/cpukit/include/rtems/thread.hpp
+++ b/cpukit/include/rtems/thread.hpp
@@ -83,14 +83,14 @@ namespace rtems
* executing thread. The stack size is set to the configured minimum
* stack size.
*/
-  attributes ();
+  attributes();
 
   /*
* Copy construct the thread attributes.
*
* @param attr The attributes to copy.
*/
-  attributes (const attributes& attr);
+  attributes(const attributes& attr);
 
   /**
* Set the name of the thread. The thread is a classic API thread and
@@ -98,7 +98,7 @@ namespace rtems
*
* @param name The name as a string.
*/
-  void set_name (const std::string& name);
+  void set_name(const std::string& name);
 
   /**
* Set the name of the thread. The thread is a classic API thread and
@@ -106,28 +106,28 @@ namespace rtems
*
* @param name The name as a string.
*/
-  void set_name (const char* name);
+  void set_name(const char* name);
 
   /**
* Get the name of the thread.
*
* @retval const std::string& The name of the thread.
*/
-  const std::string& get_name () const;
+  const std::string& get_name() const;
 
   /**
* Set the priority of the thread.
*
* @param priority The POSIX API priority of the thread.
*/
-  void set_priority (int priority);
+  void set_priority(int priority);
 
   /**
* Get the POSIX API priority of the thread.
*
* @retval int The POSIX API thread priority.
*/
-  int get_priority () const;
+  int get_priority() const;
 
   /**
* Set the stack size. If the size is less than the configured minimum
@@ -135,38 +135,38 @@ namespace rtems
*
* @param size The stack size in bytes.
*/
-  void set_stack_size (size_t size);
+  void set_stack_size(size_t size);
 
   /**
* Get the stack size.
*
* @retval size_t The stack size in bytes.
*/
-  size_t get_stack_size () const;
+  size_t get_stack_size() const;
 
   /**
* Set the scheduler name. If not set no scheduler is set.
*
* @parrm scheduler The name of the scheduler.
*/
-  void set_scheduler (const std::string& scheduler);
+  void set_scheduler(const std::string& scheduler);
 
   /**
* Set the scheduler name. If not set no scheduler is set.
*/
-  void set_scheduler (const char* scheduler);
+  void set_scheduler(const char* scheduler);
 
   /**
* Get scheduler name.
*/
-  const std::string& get_scheduler ();
+  const std::string& get_scheduler();
 
   /**
* Get the attributes' scheduler attribute for the thread.
*
* @return sched_attr The attributes' scheduler attribute
*/
-  sched_attr get_scheduler_attr () const;
+  sched_attr get_scheduler_attr() const;
 
   /**
* Set the scheduler policy for the thread. This call sets the
@@ -174,12 +174,12 @@ namespace rtems
*
* @param policy The scheduler policy.
*/
-  void set_scheduler_policy (sched_policy policy);
+  void set_scheduler_policy(sched_policy policy);

Re: [PATCH 1/2] librtemsc++: Add join() and detach() to the thread

2020-10-08 Thread Gedare Bloom 
On Thu, Oct 8, 2020 at 4:49 PM Chris Johns  wrote:
>
> On 9/10/20 3:28 am, Gedare Bloom wrote:
> > On Thu, Oct 8, 2020 at 2:19 AM  wrote:
> >>
> >> From: Chris Johns 
> >>
> >> - Do not start threads detached
> >> ---
> >>  cpukit/include/rtems/thread.hpp |  4 
> >>  cpukit/librtemscxx/thread.cpp   | 22 ++
> >>  2 files changed, 22 insertions(+), 4 deletions(-)
> >>
> >> diff --git a/cpukit/include/rtems/thread.hpp 
> >> b/cpukit/include/rtems/thread.hpp
> >> index e90e664dfa..2c4899dc0b 100644
> >> --- a/cpukit/include/rtems/thread.hpp
> >> +++ b/cpukit/include/rtems/thread.hpp
> >> @@ -321,6 +321,10 @@ namespace rtems
> >>
> >>bool joinable() const noexcept;
> >>
> >> +  void join() noexcept;
> >> +
> >> +  void detach() noexcept;
>
> Hmmm I the `noexcept` is wrong here as an exception may be raised. I will 
> remove
> these.
>
> >> +
> >>/*
> >> * Constrain use. These are not available.
> >> */
> >> diff --git a/cpukit/librtemscxx/thread.cpp b/cpukit/librtemscxx/thread.cpp
> >> index 11bf3df230..ae13201bd4 100644
> >> --- a/cpukit/librtemscxx/thread.cpp
> >> +++ b/cpukit/librtemscxx/thread.cpp
> >> @@ -346,6 +346,24 @@ namespace rtems
> >>return !(id_ == id());
> >>  }
> >>
> >> +void
> >> +thread::join() noexcept
> >> +{
> >> +  if (!joinable())
> > explicit { for 1-liners is preferred
>
> Yes ... old habits ...
>
> >> +system_error_check (ENOMEM, "join");
> > }
> >
> > In general, this file is not entirely adhering to RTEMS coding style.
> > What coding style is it? Sorry I missed this in the first patch(es)
> > adding the cxx iface
>
> It does not entirely follow the coding style as it is C++.
>
> The code was first posted in December 2019 and goes back further as I played.
> The C++ makes use of advanced template techniques, nesting classes and 
> structs,
> namespace, exceptions and more. Some of the coding standard is fine and other
> parts do not work and do not relate. I have not checked in detail.
>
I don't mind having some C++ specific rules. Maybe we can derive
something later if this keeps growing :)

> >> +  system_error_check (::pthread_join (id_.id_, nullptr), "join");
> > prefer to not have a space before the ( for function calls so that
> > function-like macros appear consistently
>
> Interesting, this is something the GNU coding standard recommends as being 
> more
> readable [1]. I did not know it was a requirement in the coding standard. I am
> not fused and can fix this but it would take a little time so let me know what
> you would like me to do? Also if you have other places that need attention
> please let me know.

You can push this with your corrections since it is self-consistent.

Maybe open a ticket for yourself to review the style later.

>
> Thanks
> Chris
>
> [1] https://www.gnu.org/prep/standards/html_node/Formatting.html#Formatting
>  It is interesting how we directly conflict with some of what it says
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: RE: I can not run rtems 5.1 smp correctly on bsp xilinx-zynqmp

2020-10-08 Thread small...@aliyun.com 
I think the key problem is the bsp_start_hook_0 function which will be executed 
in all cores.
However, this function does not distinguish each core. It means all four cores 
run the same code.
The right procedure is core 0 run the init code while other cores wait for it 
to complete.


BSP_START_TEXT_SECTION void bsp_start_hook_0(void)
{
  uint32_t sctlr_val;

  sctlr_val = arm_cp15_get_control();
  sctlr_val |= ARM_CP15_CTRL_CP15BEN;
  arm_cp15_set_control( sctlr_val );

  /*
   * Current U-boot loader seems to start kernel image
   * with I and D caches on and MMU enabled.
   * If RTEMS application image finds that cache is on
   * during startup then disable caches.
   */
  if ( sctlr_val & (ARM_CP15_CTRL_I | ARM_CP15_CTRL_C | ARM_CP15_CTRL_M ) ) {
if ( sctlr_val & (ARM_CP15_CTRL_C | ARM_CP15_CTRL_M ) ) {
  /*
   * If the data cache is on then ensure that it is clean
   * before switching off to be extra carefull.
   */
  arm_cp15_data_cache_clean_all_levels();
}
arm_cp15_flush_prefetch_buffer();
sctlr_val &= ~ ( ARM_CP15_CTRL_I | ARM_CP15_CTRL_C | ARM_CP15_CTRL_M | 
ARM_CP15_CTRL_A );
arm_cp15_set_control( sctlr_val );
  }
  arm_cp15_instruction_cache_invalidate();
  /*
   * The care should be taken there that no shared levels
   * are invalidated by secondary CPUs in SMP case.
   * It is not problem on Zynq because level of coherency
   * is L1 only and higher level is not maintained and seen
   * by CP15. So no special care to limit levels on the secondary
   * are required there.
   */
  arm_cp15_data_cache_invalidate_all_levels();
  arm_cp15_branch_predictor_invalidate_all();
  arm_cp15_tlb_invalidate();
  arm_cp15_flush_prefetch_buffer();
}



small...@aliyun.com
 
From: Kinsey Moore
Date: 2020-10-06 21:56
To: j...@rtems.org; small...@aliyun.com
CC: Gedare Bloom; devel
Subject: RE: Re: I can not run rtems 5.1 smp correctly on bsp xilinx-zynqmp
Is it possible that the application was only started on the first core instead 
of all cores? Is it possible to check the execution state of the other cores?
 
Kinsey
 
From: Joel Sherrill  
Sent: Tuesday, October 6, 2020 08:11
To: small...@aliyun.com
Cc: Gedare Bloom ; devel ; Kinsey Moore 

Subject: Re: Re: I can not run rtems 5.1 smp correctly on bsp xilinx-zynqmp
 
Maybe Kinsey has an idea. 
 
On Tue, Oct 6, 2020 at 1:29 AM small...@aliyun.com  wrote:
The board is Ultra96 board with JTAG boot.
And yes, there is a bspsmp.c in rtems-5.1\bsps\arm\xilinx-zynqmp\start\
 


small...@aliyun.com
 
From: Gedare Bloom
Date: 2020-10-06 00:16
To: small...@aliyun.com
CC: devel
Subject: Re: I can not run rtems 5.1 smp correctly on bsp xilinx-zynqmp
It should, I believe. The bsp has bspsmp.c file.
 
How did you configure (../rtems/configure)?
 
What board/target do you run it on?
 
On Mon, Oct 5, 2020 at 2:24 AM small...@aliyun.com  wrote:
> 
> Hi, all
> I compile rtems 5.1 with bsp xilinx-zynqmp. The single core mode is ok.
> But I can not use 2 or 3 or 4 cores of this bsp.
> After analysing the source code, I found there is no code to address smp 
> condition. Does rtems 5.1 indeed not support smp mode for xilinx-zynqmp bsp?
> 
> 
> small...@aliyun.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
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH v2 3/3] testsuite/rcxx01: Add examples for use in the User manual

2020-10-08 Thread Gedare Bloom 
the set looks good to me. thanks for the the style adjustments

On Thu, Oct 8, 2020 at 5:52 PM  wrote:
>
> From: Chris Johns 
>
> ---
>  spec/build/testsuites/libtests/rcxx01.yml |   3 +
>  testsuites/libtests/rcxx01/init.c |   2 +-
>  testsuites/libtests/rcxx01/thread.cpp |  21 +++-
>  testsuites/libtests/rcxx01/user-example-1.cpp |  49 
>  testsuites/libtests/rcxx01/user-example-2.cpp |  68 +++
>  testsuites/libtests/rcxx01/user-example-3.cpp | 113 ++
>  6 files changed, 251 insertions(+), 5 deletions(-)
>  create mode 100644 testsuites/libtests/rcxx01/user-example-1.cpp
>  create mode 100644 testsuites/libtests/rcxx01/user-example-2.cpp
>  create mode 100644 testsuites/libtests/rcxx01/user-example-3.cpp
>
> diff --git a/spec/build/testsuites/libtests/rcxx01.yml 
> b/spec/build/testsuites/libtests/rcxx01.yml
> index 864ad4d9d6..49bd9cff66 100644
> --- a/spec/build/testsuites/libtests/rcxx01.yml
> +++ b/spec/build/testsuites/libtests/rcxx01.yml
> @@ -13,6 +13,9 @@ links: []
>  source:
>  - testsuites/libtests/rcxx01/init.c
>  - testsuites/libtests/rcxx01/thread.cpp
> +- testsuites/libtests/rcxx01/user-example-1.cpp
> +- testsuites/libtests/rcxx01/user-example-2.cpp
> +- testsuites/libtests/rcxx01/user-example-3.cpp
>  stlib: []
>  target: testsuites/libtests/rcxx01.exe
>  type: build
> diff --git a/testsuites/libtests/rcxx01/init.c 
> b/testsuites/libtests/rcxx01/init.c
> index 87d3155c7f..bea71d14c7 100644
> --- a/testsuites/libtests/rcxx01/init.c
> +++ b/testsuites/libtests/rcxx01/init.c
> @@ -72,7 +72,7 @@ rtems_task Init(
>  #define CONFIGURE_MEMORY_OVERHEAD (2024)
>
>  #define CONFIGURE_MAXIMUM_TASKS  1
> -#define CONFIGURE_MAXIMUM_POSIX_THREADS 2
> +#define CONFIGURE_MAXIMUM_POSIX_THREADS 5
>
>  #define CONFIGURE_INITIAL_EXTENSIONS RTEMS_TEST_INITIAL_EXTENSION
>
> diff --git a/testsuites/libtests/rcxx01/thread.cpp 
> b/testsuites/libtests/rcxx01/thread.cpp
> index 05a9de8c48..f977a340a9 100644
> --- a/testsuites/libtests/rcxx01/thread.cpp
> +++ b/testsuites/libtests/rcxx01/thread.cpp
> @@ -36,6 +36,10 @@ using namespace std::chrono_literals;
>
>  extern "C" void rcxx_run_test(void);
>
> +void example_1();
> +void example_2();
> +void example_3();
> +
>  struct test_thread
>  {
>test_thread();
> @@ -96,13 +100,22 @@ bool test_thread::running()
>return finished == false;
>  }
>
> +void test_1()
> +{
> +  test_thread tt;
> +  tt.start();
> +  while (tt.running())
> +std::this_thread::sleep_for(1s);
> +}
> +
>  void rcxx_run_test(void)
>  {
>try {
> -test_thread tt;
> -tt.start();
> -while (tt.running())
> -  std::this_thread::sleep_for(1s);
> +test_1();
> +/* From the user manual */
> +example_1();
> +example_2();
> +example_3();
>} catch (...) {
>  std::cout << "Thread: ouch" << std::endl;
>  throw;
> diff --git a/testsuites/libtests/rcxx01/user-example-1.cpp 
> b/testsuites/libtests/rcxx01/user-example-1.cpp
> new file mode 100644
> index 00..dfc0992193
> --- /dev/null
> +++ b/testsuites/libtests/rcxx01/user-example-1.cpp
> @@ -0,0 +1,49 @@
> +/* SPDX-License-Identifier: BSD-2-Clause */
> +
> +/*
> + * Copyright (C) 2020 Chris Johns (http://contemporary.software)
> + *
> + * Redistribution and use in source and binary forms, with or without
> + * modification, are permitted provided that the following conditions
> + * are met:
> + * 1. Redistributions of source code must retain the above copyright
> + *notice, this list of conditions and the following disclaimer.
> + * 2. Redistributions in binary form must reproduce the above copyright
> + *notice, this list of conditions and the following disclaimer in the
> + *documentation and/or other materials provided with the distribution.
> + *
> + * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS 
> IS"
> + * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
> + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
> + * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE
> + * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
> + * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
> + * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
> + * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
> + * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
> + * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
> + * POSSIBILITY OF SUCH DAMAGE.
> + */
> +
> +#include 
> +#include 
> +
> +#include 
> +
> +static void wait_for(size_t seconds)
> +{
> +  while (seconds--) {
> +std::this_thread::sleep_for(std::chrono::seconds(1));
> +std::cout << "Seconds: " << seconds << std::endl;
> +  }
> +}
> +
> +void example_1()
> +{
> +  std::cout << "Start example 1" << std::endl;
> +
> +  rtems::thread::thread t(wait_

[PATCH] user: Add a Languages section

2020-10-08 Thread chrisj 
From: Chris Johns 

---
 user/index.rst   |   2 +
 user/languages/c.rst |  14 ++
 user/languages/cpp.rst   | 312 +++
 user/languages/index.rst |  21 +++
 4 files changed, 349 insertions(+)
 create mode 100644 user/languages/c.rst
 create mode 100644 user/languages/cpp.rst
 create mode 100644 user/languages/index.rst

diff --git a/user/index.rst b/user/index.rst
index a91aa55..32667f4 100644
--- a/user/index.rst
+++ b/user/index.rst
@@ -42,6 +42,8 @@ RTEMS User Manual (|version|).
 bld/index
 bsps/index
 
+languages/index
+
 exe/index
 testing/index
 tracing/index
diff --git a/user/languages/c.rst b/user/languages/c.rst
new file mode 100644
index 000..c3965eb
--- /dev/null
+++ b/user/languages/c.rst
@@ -0,0 +1,14 @@
+.. SPDX-License-Identifier: CC-BY-SA-4.0
+
+.. Copyright (C) 2020 Chris Johns 
+
+.. index:: C
+.. index:: C Programming Language
+
+C
+=
+.. index:: C
+
+RTEMS supports the C programming language.
+
+TBD.
diff --git a/user/languages/cpp.rst b/user/languages/cpp.rst
new file mode 100644
index 000..8a8cb86
--- /dev/null
+++ b/user/languages/cpp.rst
@@ -0,0 +1,312 @@
+.. SPDX-License-Identifier: CC-BY-SA-4.0
+
+.. Copyright (C) 2020 Chris Johns 
+
+.. index:: C++
+.. index:: C++ Programming Language
+
+C++
+===
+.. index:: C++
+
+RTEMS supports the C++ programming language and its standard library. The
+supported language versions are C++11, C++14, and C++17.
+
+The C++ standard library provides a rich set of interfaces to support
+multi-threaded programming. The Thread support library provides
+``std::lock_guard`` as a means to manage ``std::mutex`` or similar objects
+within a code block while execution remains within that block. The
+``std::promise`` and ``std::future`` supports provides a controlled means for
+threads to end, clean-up and return a status value of some type. The Atomic
+operations library provdes a range of methods to atomically acess data as well
+as establish inter-thread synchronization and order non-atomic memory
+accesses.
+
+The Thread support library maps to the RTEMS POSIX ``pthread`` interface and
+the various sychronisation primatives such as mutual exclusion, condition
+variables, and futures map to the high performance self-contained RTEMS
+interface. These objects have a fast execution profile and their storage is
+self-contained which means it does not have to be accounted for in the
+configuration and work-space settings. C++ applications do not need to be
+concerned about the number of locks being used and can implement fine grain
+locking protocols.
+
+RTEMS Threads
+-
+
+RTEMS provides an alternative Thread interface that lets you specify the
+attributes of a thread when it is constructed. This is an extension to the
+standard and is not based on any current or pending standards efforts. The
+goal is to make the interface as close as possible to the existing standard to
+minimise the impact on code being ported to RTEMS.
+
+The following compiler option must be used as the implementation uses the
+``std::invoke`` call which is only available with C++17:
+
+.. code-block:: c++
+
+   --std=c++17
+
+The standard Thread support library specifies the thread constructor as:
+
+.. code-block:: c++
+
+   template< class Function, class... Args >
+   explicit thread( Function&& f, Args&&... args );
+
+A thread constructed using this interface will have a default set of initial
+values. An important atribute of a thread is the stack size and this cannot be
+specified or altered with this interface. On Unix systems virtual memory can
+be used to manage a thread's stack size and stack handling is more complex
+when security is considered so manually controlling the stack size of a thread
+is not needed or wanted.
+
+Attributes
+^^
+
+The ``rtems::thread::attributes`` class provides an interface to control the
+various attributes a thread has. The header file is:
+
+.. code-block:: c++
+
+   #include 
+
+The default constructor initialises the attributes to the executing thread's
+settings and the stack size is set to the configured minimum. You can then
+alter the attributes to match the requirements of the new thread. It is easy
+to set a name, stack size and priority:
+
+.. code-block:: c++
+
+   rtems::thread::attribute attr;
+   attr.set_name("blue");
+   attr.set_stack_size(16 * 1024);
+   attr.set_priority(attr.get_priority() + 1);
+
+The ``update()`` method will read the attributes of the currently executing
+thread and update the attribute instance making the call. The stack size is
+not read and updated, there is no public interface in RTEMS to obtain the
+executing thread's stack size.
+
+An attribute object can be used to start a number of threads. The thread does
+not referenced the attribute object once running.
+
+An attribute object can be used to alter an attribute of a thread after it has
+started by calling the ``commit()`` method. The ``commit()`` method

Re: [PATCH v2 3/3] testsuite/rcxx01: Add examples for use in the User manual

2020-10-08 Thread Chris Johns 
On 9/10/20 2:45 pm, Gedare Bloom wrote:
> the set looks good to me. thanks for the the style adjustments

Great and again thanks for the review.

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

Re: [PATCH] user: Add a Languages section

2020-10-08 Thread Sebastian Huber 

Hello Chris,

I think API descriptions should go into the RTEMS Classic API Guide. 
Maybe we should rename this manual.


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

Re: [PATCH] user: Add a Languages section

2020-10-08 Thread Chris Johns 
On 9/10/20 4:48 pm, Sebastian Huber wrote:
> I think API descriptions should go into the RTEMS Classic API Guide.

Which bit or the whole thing?

The patch is more about an example of threading in C++ and the standards
addition I have added than more formal API documentation. I can add a more
formal API section if we think there is a need but the thread class itself is
documented in the standard already. I think we need a languages section.

The scheduling bits can be (re)moved if needed. I could not find anything in the
POSIX manual I could reference.

> Maybe we should rename this manual.

Do you have a name in mind?

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