RTEMS Pre-Qualification Status

2020-09-29 Thread Sebastian Huber 

Hello,

I would like to give a status report about the RTEMS pre-qualification 
activity and an outlook to the work ahead. Since my last report in July 
this year


https://lists.rtems.org/pipermail/devel/2020-July/060566.html

a lot happened in the RTEMS Project. The RTEMS specification repository 
is now included in the set of RTEMS Project repositories:


https://lists.rtems.org/pipermail/devel/2020-July/060914.html

One goal of the RTEMS specification is to establish a centralized data 
set which can be used to generate source code and documentation sources 
for the referenced modules (RTEMS sources and documentation).


The RTEMS 5.1 release in August

https://lists.rtems.org/pipermail/users/2020-August/067811.html

made it possible to integrate the first bigger chunks of work resulting 
from the pre-qualification activity.


Firstly, the new build system was integrated:

https://git.rtems.org/rtems/commit/?id=f3f0370f1054f4e49aa8f5ea70485d673e8e94b6

The development of the new build system started in August 2019 and was 
basically finished in November 2019. The new build system uses 
specification items which can be re-used in the RTEMS pre-qualification 
activity:


https://docs.rtems.org/branches/master/eng/req/items.html#spectypebuilditemtype

Secondly, two new directives are now available: rtems_task_construct() 
and rtems_message_queue_construct(). The key feature of these two 
directives is that they use user-provided instead of system-provided 
storage to construct the object. This makes it possible to build 
applications which use only statically allocated storage and do not use 
the RTEMS Workspace. This helps to implement the so called space profile 
subset of RTEMS. The space profile was determined by a user survey last 
year:


https://lists.rtems.org/pipermail/users/2019-March/032977.html

The specification, validation, and documentation of these two new 
directives is still incomplete, however, they already give a proof of 
concept of the specification work flow. For example, the Doxygen markup 
and the declarations in the header files are generated from the 
specification. The error cases are specified by action requirements and 
the generated test cases are included in the RTEMS sources along with a 
general purpose validation test suite:


https://git.rtems.org/rtems/tree/testsuites/validation

Thirdly, the first header and documentation files generated from the 
specification are included in the RTEMS sources:


https://git.rtems.org/rtems/tree/cpukit/include/rtems.h#n38

https://git.rtems.org/rtems/tree/cpukit/doxygen/appl-config.h#n31

What are the next steps?

The API defined by  is already fully specified and I can build 
RTEMS and all tests with it. What is missing are the documentation parts 
included in the interface specification. Once this information is 
available in the specification items, we can generate the header files 
with Doxygen markup and the Sphinx documentation sources for the manuals 
from the same data set. For this I have to review the existing 
documentation in the header files and the documentation sources and 
consolidate the information in the corresponding specification items. I 
completed this work already for the Event Manager and the IO Manager and 
will it send soon for review to the RTEMS mailing list. I hope to have 
all managers converted by the end of the year.


Parallel to the interface specification and documentation we work on the 
functional specification of the interfaces and the validation tests. 
This will mostly result in new test cases and test suites.


There are some topics left for the RTEMS Software Engineering manual. We 
had some discussions about the use of static analysis tools in RTEMS. I 
think the results of the discussion should be added to a new chapter or 
section. We should discuss if, which, and how code quality metrics can 
be used in the RTEMS Project.


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

Re: [PATCH v2 1/8] Move ARM PL011 UART driver

2020-09-29 Thread Sebastian Huber 

On 28/09/2020 17:24, Kinsey Moore wrote:


This UART driver is now needed for BSPs other than ARM.
---
  bsps/arm/headers.am| 2 --
  bsps/arm/raspberrypi/console/console-config.c  | 2 +-
  bsps/arm/realview-pbx-a9/include/bsp/console.h | 2 +-
  bsps/arm/xen/console/console.c | 2 +-
  bsps/headers.am| 2 ++
  bsps/{arm/include/bsp => include/libchip}/arm-pl011-regs.h | 0
  bsps/{arm/include/bsp => include/libchip}/arm-pl011.h  | 2 +-


For me this libchip inline stuff is a legacy thing. If you really want 
to change the include path, then I suggest to move the serial driver 
header files to:


bsps/shared/include/dev/serial

This is in line with cpukit/include/dev/serial and the source location 
bsps/shared/dev/serial.


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

Re: [PATCH v2 2/8] spec: Add missing spintrcritical24 definition

2020-09-29 Thread Sebastian Huber 

On 28/09/2020 17:24, Kinsey Moore wrote:


---
  spec/build/bsps/tstnointrcrit.yml | 1 +
  1 file changed, 1 insertion(+)

diff --git a/spec/build/bsps/tstnointrcrit.yml 
b/spec/build/bsps/tstnointrcrit.yml
index 0460aaabb3..46f7d974c8 100644
--- a/spec/build/bsps/tstnointrcrit.yml
+++ b/spec/build/bsps/tstnointrcrit.yml
@@ -24,6 +24,7 @@ actions:
  spintrcritical21: exclude
  spintrcritical22: exclude
  spintrcritical23: exclude
+spintrcritical24: exclude
  build-type: option
  copyrights:
  - Copyright (C) 2020 embedded brains GmbH (http://www.embedded-brains.de)


I changed the test support for critical sections recently. Now, this 
test framework part is used:


https://docs.rtems.org/branches/master/eng/test-framework.html#interrupt-tests

Could you please run the spintrcritical* tests also on the new port. My 
intention was to be able to run these tests on Qemu.


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

Re: [PATCH v2 3/8] bsps: Break out AArch32 portions of GPT driver

2020-09-29 Thread Sebastian Huber 

On 28/09/2020 17:24, Kinsey Moore wrote:


  create mode 100644 bsps/include/bsp/clock-arm-generic-timer.h
  rename bsps/{arm/shared/clock/clock-generic-timer.c => 
shared/clock/clock-arm-generic-timer.c} (71%)


I would add it as:

bsps/shared/dev/clock/arm-generic-timer.c

bsps/include/dev/clock/arm-generic-timer.h

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

Re: [PATCH v2 4/8] bsps: Break out AArch32 GICv3 support

2020-09-29 Thread Sebastian Huber 

On 28/09/2020 17:24, Kinsey Moore wrote:


This breaks out AArch32-specific code so that the shared GICv3 code can
be reused by other architectures.


I would place the shared IRQ controller support in:

bsps/include/dev/irq

bsps/shared/dev/irq

The bsp_interrupt_dispatch() is declared in:

cpukit/score/cpu/arm/include/rtems/score/armv4.h

Since it is used by:

cpukit/score/cpu/arm/arm_exc_interrupt.S

I think you should declare this function in:

cpukit/score/cpu/aarch64/include/rtems/score/*.h

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

Re: [PATCH v2 5/8] bsps/shared: Add PSCI-based bspreset implementation

2020-09-29 Thread Sebastian Huber 

On 28/09/2020 17:24, Kinsey Moore wrote:


This adds a bsp_reset implementation based on the ARM PSCI
specification often present in ARMv8 systems.
---
  bsps/shared/start/bspreset-psci.c | 56 +++

Maybe name it bspreset-arm-psci.c
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH v2 6/8] score: Add AArch64 port

2020-09-29 Thread Sebastian Huber 

On 28/09/2020 17:24, Kinsey Moore wrote:


diff --git a/cpukit/include/rtems/score/tls.h b/cpukit/include/rtems/score/tls.h
index 65a49d87be..66961f0083 100644
--- a/cpukit/include/rtems/score/tls.h
+++ b/cpukit/include/rtems/score/tls.h
@@ -85,7 +85,9 @@ typedef struct TLS_Thread_control_block {
struct TLS_Thread_control_block *tcb;
  #else /* !__i386__ */
TLS_Dynamic_thread_vector *dtv;
-#if CPU_SIZEOF_POINTER == 4
+/* gcc under AArch64/LP64 expects a 16 byte TCB at the beginning of the TLS
+ * data segment and indexes into it accordingly for TLS variable addresses */
+#if CPU_SIZEOF_POINTER == 4 || defined(AARCH64_MULTILIB_ARCH_V8)
uintptr_t reserved;
  #endif
  #endif /* __i386__ */


Multi line comments should have the format:

/*
 * I am a complete
 * sentence.
 */

It should be GCC instead of gcc.

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

Re: [PATCH v2 6/8] score: Add AArch64 port

2020-09-29 Thread Sebastian Huber 

On 28/09/2020 17:24, Kinsey Moore wrote:


+/* TODO(kmoore) The current implementation here assumes that SP is not 
misaligned */

Maybe add a ticket for this TODO and reference it in the comment.

+   .macro  JUMP_HANDLER
+   mov x0, #0x7f   /* mask to use in BIC, lower 7 bits */
+   bic x0, lr, x0  /* lr contains PC, mask off to the base 
of the current vector */
+   ldr x0, [x0,#0x78]  /* load address from the last word in 
the vector */
+   blr x0  /* branch and link to address in x0, no 
reason to save current LR since it has already been saved and current contents 
are junk */
+   ldp x0, lr, [sp],   #16 /* pop x0,lr from stack */
+   eret/* return from exception */
Some lines are longer than 79 characters. I spotted also // comments. I 
have nothing against // comments in general, but before we introduce 
them, it would be good to update the coding style.

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

Re: [PATCH v2 6/8] score: Add AArch64 port

2020-09-29 Thread Sebastian Huber 

On 28/09/2020 17:24, Kinsey Moore wrote:


+#include 
+
+
+void *_CPU_Thread_Idle_body( uintptr_t ignored )
+{
+  while ( true ) {
+__asm__ volatile ("wfi");
+  }
+}
+

Too many blank lines.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH v2 6/8] score: Add AArch64 port

2020-09-29 Thread Sebastian Huber 

On 28/09/2020 17:24, Kinsey Moore wrote:


+  RTEMS_STATIC_ASSERT(
+offsetof( Context_Control, thread_id )
+  == AARCH64_CONTEXT_CONTROL_THREAD_ID_OFFSET,
+AARCH64_CONTEXT_CONTROL_THREAD_ID_OFFSET
+  );


Wrong indentation level.

It would be good to add assertions for all offset defines. Errors in 
these offsets can lead to hard to find sporadic bugs.


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

Re: [PATCH v2 7/8] bsps: Add Cortex-A53 LP64 basic BSP

2020-09-29 Thread Sebastian Huber 

On 28/09/2020 17:24, Kinsey Moore wrote:


diff --git a/bsps/aarch64/shared/start/linkcmds.base 
b/bsps/aarch64/shared/start/linkcmds.base
new file mode 100644
index 00..f67404ab62
--- /dev/null
+++ b/bsps/aarch64/shared/start/linkcmds.base
@@ -0,0 +1,450 @@
+/* SPDX-License-Identifier: BSD-2-Clause */
+
+/**
+ * @file
+ *
+ * @ingroup bsp_linker
+ *
+ * @brief Linker command base file.
+ */
+
+/*
+ * Copyright (C) 2020 On-Line Applications Research Corporation (OAR)
+ * Written by Kinsey Moore
This looks like a modified copy of bsps/arm/shared/start/linkcmds.base. 
Are there significant differences or could we share this linker script 
on arm and aarch64?

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

Re: License files missing on 5-freebsd-12 branch

2020-09-29 Thread Christian Mauderer 
On 29/09/2020 03:35, Chris Johns wrote:
> On 28/9/20 9:45 pm, Christian Mauderer wrote:
>> Sorry for the delay. I didn't manage to do these before my vacation and
>> then I forgot them during vacation. I just pushed them.
> 
> No problem and thank you. I hope you had a relaxing vacation?
> 
> Chris
> 

Like every vacation, it was too short. Otherwise: Yes, it was relaxing.

Best regards

Christian

-- 

embedded brains GmbH
Herr Christian Mauderer
Dornierstr. 4
D-82178 Puchheim
Germany
email: christian.maude...@embedded-brains.de
Phone: +49-89-18 94 741 - 18
Fax:   +49-89-18 94 741 - 08
PGP: Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH v2 8/8] bsps: Add Cortex-A53 ILP32 BSP variant

2020-09-29 Thread Sebastian Huber 

On 28/09/2020 17:24, Kinsey Moore wrote:


diff --git a/spec/build/bsps/aarch64/a53/bspa53ilp32qemu.yml 
b/spec/build/bsps/aarch64/a53/bspa53ilp32qemu.yml
new file mode 100644
index 00..3e32999860
--- /dev/null
+++ b/spec/build/bsps/aarch64/a53/bspa53ilp32qemu.yml
@@ -0,0 +1,73 @@
+SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
+arch: aarch64
+bsp: a53_ilp32_qemu
+build-type: bsp
+cflags: []
+copyrights:
+- Copyright (C) 2020 On-Line Applications Research (OAR)
+cppflags: []
+enabled-by: true
+family: a53
+includes: []
+install:
+- destination: ${BSP_INCLUDEDIR}
+  source:
+  - bsps/aarch64/a53/include/bsp.h
+  - bsps/aarch64/a53/include/tm27.h
+- destination: ${BSP_INCLUDEDIR}/bsp
+  source:
+  - bsps/aarch64/a53/include/bsp/irq.h
+  - bsps/include/bsp/arm-gic-irq.h
+  - bsps/include/bsp/arm-gic-regs.h
+  - bsps/include/bsp/arm-gic-tm27.h
+  - bsps/include/bsp/arm-gic.h
+  - bsps/aarch64/include/bsp/irq-arch.h
+  - bsps/include/bsp/clock-arm-generic-timer.h
+links:
+- role: build-dependency
+  uid: ../start
+- role: build-dependency
+  uid: abi
+- role: build-dependency
+  uid: optloadoff
+- role: build-dependency
+  uid: optnocachelen
+- role: build-dependency
+  uid: optramlen
+- role: build-dependency
+  uid: optramori
+- role: build-dependency
+  uid: tsta53
+- role: build-dependency
+  uid: ../../obj
+- role: build-dependency
+  uid: ../../objirq
+- role: build-dependency
+  uid: ../../optcachedata
+- role: build-dependency
+  uid: ../../optcacheinst
+- role: build-dependency
+  uid: ../../opto2
+- role: build-dependency
+  uid: linkcmds_ilp32
+- role: build-dependency
+  uid: ../../bspopts
+source:
+- bsps/aarch64/shared/cache/cache.c
+- bsps/aarch64/a53/console/console.c
+- bsps/aarch64/a53/start/bspstart.c
+- bsps/aarch64/a53/start/bspstarthooks.c
+- bsps/shared/dev/getentropy/getentropy-cpucounter.c
+- bsps/shared/dev/serial/console-termios-init.c
+- bsps/shared/dev/serial/console-termios.c
+- bsps/shared/start/bspfatal-default.c
+- bsps/shared/start/bspgetworkarea-default.c
+- bsps/shared/start/bspreset-psci.c
+- bsps/shared/start/sbrk.c
+- bsps/shared/irq/irq-arm-gicv3.c
+- bsps/shared/irq/irq-default-handler.c
+- bsps/aarch64/shared/irq/irq-arm-gicv3-aarch64.c
+- bsps/shared/dev/btimer/btimer-cpucounter.c
+- bsps/shared/clock/clock-arm-generic-timer.c
+- bsps/aarch64/shared/clock/clock-arm-generic-timer-aarch64.c


This looks like a copy and paste variant of the other BSP. Please use a 
grp.yml:


https://docs.rtems.org/branches/master/eng/build-system.html#id4

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

RE: [PATCH v2 1/2] cpu-supplement: Fix formatting and missing words

2020-09-29 Thread Kinsey Moore 
It was already an odd hybrid of a marked up list and a grammatical list that I 
noticed while I was working on the AArch64 documentation. I figured I'd push it 
one way or the other since mixing the constructs looks weird, but I can drop 
the changes unrelated to AArch64 if you prefer.

Kinsey

-Original Message-
From: Sebastian Huber  
Sent: Monday, September 28, 2020 23:36
To: Kinsey Moore ; devel@rtems.org
Subject: Re: [PATCH v2 1/2] cpu-supplement: Fix formatting and missing words

On 28/09/2020 17:25, Kinsey Moore wrote:

> @@ -196,11 +196,11 @@ Symmetric Multiprocessing
>   
>   SMP is supported on ARMv7-A.  Available platforms are
>   
> -- Altera Cyclone V,
> +- Altera Cyclone V
>   
> -- NXP i.MX 7, and
> +- NXP i.MX 7
>   
> -- Xilinx Zynq.
> +- Xilinx Zynq

What is the reason for this change?


If you change the formatting like this, then it should be

"Available platforms are:"

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

RE: [PATCH v2 2/2] Add AArch64 documentation

2020-09-29 Thread Kinsey Moore 
There are some rudimentary pieces of SMP support in the port itself, but it is 
certainly not complete and is untested. That work is planned for the next phase 
of development at which point I'll update the BSPs to support that as well if 
they require any changes at all.

Kinsey

-Original Message-
From: Sebastian Huber  
Sent: Monday, September 28, 2020 23:40
To: Kinsey Moore ; devel@rtems.org
Subject: Re: [PATCH v2 2/2] Add AArch64 documentation

On 28/09/2020 17:25, Kinsey Moore wrote:

> +Symmetric Multiprocessing
> +=
> +
> +SMP is not currently supported on ARMv8-A.
Is this a limitation of the CPU port or just a missing BSP support?
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

RE: [PATCH v2 1/8] Move ARM PL011 UART driver

2020-09-29 Thread Kinsey Moore 
I'll include this change in the next version of the patch.

Kinsey

-Original Message-
From: Sebastian Huber  
Sent: Tuesday, September 29, 2020 05:59
To: Kinsey Moore ; devel@rtems.org
Subject: Re: [PATCH v2 1/8] Move ARM PL011 UART driver

On 28/09/2020 17:24, Kinsey Moore wrote:

> This UART driver is now needed for BSPs other than ARM.
> ---
>   bsps/arm/headers.am| 2 --
>   bsps/arm/raspberrypi/console/console-config.c  | 2 +-
>   bsps/arm/realview-pbx-a9/include/bsp/console.h | 2 +-
>   bsps/arm/xen/console/console.c | 2 +-
>   bsps/headers.am| 2 ++
>   bsps/{arm/include/bsp => include/libchip}/arm-pl011-regs.h | 0
>   bsps/{arm/include/bsp => include/libchip}/arm-pl011.h  | 2 +-

For me this libchip inline stuff is a legacy thing. If you really want to 
change the include path, then I suggest to move the serial driver header files 
to:

bsps/shared/include/dev/serial

This is in line with cpukit/include/dev/serial and the source location 
bsps/shared/dev/serial.

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

RE: [PATCH v2 2/8] spec: Add missing spintrcritical24 definition

2020-09-29 Thread Kinsey Moore 
-Original Message-
From: Sebastian Huber  
Sent: Tuesday, September 29, 2020 06:09
To: Kinsey Moore ; RTEMS 
Subject: Re: [PATCH v2 2/8] spec: Add missing spintrcritical24 definition

On 28/09/2020 17:24, Kinsey Moore wrote:

> ---
>   spec/build/bsps/tstnointrcrit.yml | 1 +
>   1 file changed, 1 insertion(+)
>
> diff --git a/spec/build/bsps/tstnointrcrit.yml 
> b/spec/build/bsps/tstnointrcrit.yml
> index 0460aaabb3..46f7d974c8 100644
> --- a/spec/build/bsps/tstnointrcrit.yml
> +++ b/spec/build/bsps/tstnointrcrit.yml
> @@ -24,6 +24,7 @@ actions:
>   spintrcritical21: exclude
>   spintrcritical22: exclude
>   spintrcritical23: exclude
> +spintrcritical24: exclude
>   build-type: option
>   copyrights:
>   - Copyright (C) 2020 embedded brains GmbH 
> (http://www.embedded-brains.de)

I changed the test support for critical sections recently. Now, this test 
framework part is used:

https://docs.rtems.org/branches/master/eng/test-framework.html#interrupt-tests

Could you please run the spintrcritical* tests also on the new port. My 
intention was to be able to run these tests on Qemu.

[] 
I'll make sure these are working before I push the next patch version.

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

[PATCH] tests: Add and use

2020-09-29 Thread Sebastian Huber 
Add the build option RTEMS_TEST_VERBOSITY to control the verbosity of
test suites using the RTEMS test framework.
---
 spec/build/testsuites/grp.yml |  2 ++
 spec/build/testsuites/optverbosity.yml| 27 +++
 spec/build/testsuites/testopts.yml| 13 +++
 testsuites/smptests/smpmulticast01/init.c |  3 ++-
 testsuites/validation/ts-validation-0.c   |  3 ++-
 5 files changed, 46 insertions(+), 2 deletions(-)
 create mode 100644 spec/build/testsuites/optverbosity.yml
 create mode 100644 spec/build/testsuites/testopts.yml

diff --git a/spec/build/testsuites/grp.yml b/spec/build/testsuites/grp.yml
index 5c6457f06d..fa2bad1016 100644
--- a/spec/build/testsuites/grp.yml
+++ b/spec/build/testsuites/grp.yml
@@ -62,6 +62,8 @@ links:
   uid: tmtests/grp
 - role: build-dependency
   uid: validation/grp
+- role: build-dependency
+  uid: testopts
 type: build
 use-after:
 - rtemscpu
diff --git a/spec/build/testsuites/optverbosity.yml 
b/spec/build/testsuites/optverbosity.yml
new file mode 100644
index 00..92fd9dfa7d
--- /dev/null
+++ b/spec/build/testsuites/optverbosity.yml
@@ -0,0 +1,27 @@
+SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
+actions:
+- get-string: null
+- script: |
+verbosities = {
+"Verbose": "T_VERBOSE",
+"Normal": "T_NORMAL",
+"Quiet": "T_QUIET",
+}
+name = self.data["name"]
+try:
+conf.define(name, verbosities[value], quote=False)
+except KeyError:
+conf.fatal("The value of {} shall be one of {}".format(
+   name, verbosities.keys()))
+build-type: option
+copyrights:
+- Copyright (C) 2020 embedded brains GmbH (http://www.embedded-brains.de)
+default: Normal
+default-by-variant: []
+description: |
+  Sets the test verbosity.  Valid values are "Verbose", "Normal", and "Quiet".
+enabled-by: true
+format: '{}'
+links: []
+name: RTEMS_TEST_VERBOSITY
+type: build
diff --git a/spec/build/testsuites/testopts.yml 
b/spec/build/testsuites/testopts.yml
new file mode 100644
index 00..8b6ab38f56
--- /dev/null
+++ b/spec/build/testsuites/testopts.yml
@@ -0,0 +1,13 @@
+SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
+build-type: config-header
+copyrights:
+- Copyright (C) 2020 embedded brains GmbH (http://www.embedded-brains.de)
+enabled-by: true
+guard: _RTEMS_TESTOPTS_H
+include-headers: []
+install-path: ${BSP_INCLUDEDIR}/rtems
+links:
+- role: build-dependency
+  uid: optverbosity
+target: cpukit/include/rtems/testopts.h
+type: build
diff --git a/testsuites/smptests/smpmulticast01/init.c 
b/testsuites/smptests/smpmulticast01/init.c
index f5ed70952a..3d2412427c 100644
--- a/testsuites/smptests/smpmulticast01/init.c
+++ b/testsuites/smptests/smpmulticast01/init.c
@@ -34,6 +34,7 @@
 #include 
 
 #include 
+#include 
 #include 
 
 #define CPU_COUNT 32
@@ -43,7 +44,7 @@ const char rtems_test_name[] = "SMPMULTICAST 1";
 static const T_config config = {
   .name = "SMPMultiCast",
   .putchar = T_putchar_default,
-  .verbosity = T_VERBOSE,
+  .verbosity = RTEMS_TEST_VERBOSITY,
   .now = T_now_clock
 };
 
diff --git a/testsuites/validation/ts-validation-0.c 
b/testsuites/validation/ts-validation-0.c
index 3e60fb6ab8..0d641637ee 100644
--- a/testsuites/validation/ts-validation-0.c
+++ b/testsuites/validation/ts-validation-0.c
@@ -49,6 +49,7 @@
 #include 
 
 #include 
+#include 
 
 /**
  * @defgroup RTEMSTestSuiteTestsuitesValidation0 spec:/testsuites/validation-0
@@ -88,7 +89,7 @@ static const T_config test_config = {
   .buf = buffer,
   .buf_size = sizeof( buffer ),
   .putchar = rtems_put_char,
-  .verbosity = T_VERBOSE,
+  .verbosity = RTEMS_TEST_VERBOSITY,
   .now = T_now_clock,
   .action_count = T_ARRAY_SIZE( actions ),
   .actions = actions
-- 
2.26.2

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

Purpose of rtems_device_driver?

2020-09-29 Thread Sebastian Huber 

Hello,

I work currently on the documentation of the IO Manager. What is the 
purpose of


typedef rtems_status_code rtems_device_driver;

?

For me this looks a bit like camouflage.

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

Re: Purpose of rtems_device_driver?

2020-09-29 Thread Joel Sherrill 
On Tue, Sep 29, 2020 at 8:37 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> Hello,
>
> I work currently on the documentation of the IO Manager. What is the
> purpose of
>
> typedef rtems_status_code rtems_device_driver;
>
> ?
>
> For me this looks a bit like camouflage.
>

No. It is a use of typedef to make the purpose of the method clear.

You have nibbled at these for years. There were at least types for
Classic Tasks, ASRs, and TSRs at one point.

If this is the last one, I'm not going to fight it. This isn't the hill I am
going to die on.

--joel

>
> ___
> 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: Purpose of rtems_device_driver?

2020-09-29 Thread Sebastian Huber 

On 29/09/2020 15:42, Joel Sherrill wrote:




On Tue, Sep 29, 2020 at 8:37 AM Sebastian Huber 
> wrote:


Hello,

I work currently on the documentation of the IO Manager. What is the
purpose of

typedef rtems_status_code rtems_device_driver;

?

For me this looks a bit like camouflage.


No. It is a use of typedef to make the purpose of the method clear.

You have nibbled at these for years. There were at least types for
Classic Tasks, ASRs, and TSRs at one point.

Yes, the typedefs to void.


If this is the last one, I'm not going to fight it. This isn't the 
hill I am

going to die on.
I am not suggesting to remove them although I find these typedefs pretty 
odd. I just look for some documentation text.

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

Re: Purpose of rtems_device_driver?

2020-09-29 Thread Sebastian Huber 

On 29/09/2020 15:47, Sebastian Huber wrote:


On 29/09/2020 15:42, Joel Sherrill wrote:




On Tue, Sep 29, 2020 at 8:37 AM Sebastian Huber 
> wrote:


    Hello,

    I work currently on the documentation of the IO Manager. What is the
    purpose of

    typedef rtems_status_code rtems_device_driver;

    ?

    For me this looks a bit like camouflage.


No. It is a use of typedef to make the purpose of the method clear.

You have nibbled at these for years. There were at least types for
Classic Tasks, ASRs, and TSRs at one point.

Yes, the typedefs to void.


If this is the last one, I'm not going to fight it. This isn't the 
hill I am

going to die on.
I am not suggesting to remove them although I find these typedefs 
pretty odd. I just look for some documentation text.


What about this:

/**
 * @ingroup RTEMSAPIClassicIO
 *
 * @brief This type shall be used in device driver entry declarations and
 *   definitions.
 *
 * Device driver entries return an #rtems_status_code status code. This 
type

 * definition helps to document device driver entries in the source code.
 */
typedef rtems_status_code rtems_device_driver;

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

Re: Purpose of rtems_device_driver?

2020-09-29 Thread Joel Sherrill 
On Tue, Sep 29, 2020 at 8:54 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> On 29/09/2020 15:47, Sebastian Huber wrote:
>
> > On 29/09/2020 15:42, Joel Sherrill wrote:
> >
> >>
> >>
> >> On Tue, Sep 29, 2020 at 8:37 AM Sebastian Huber
> >>  >> > wrote:
> >>
> >> Hello,
> >>
> >> I work currently on the documentation of the IO Manager. What is the
> >> purpose of
> >>
> >> typedef rtems_status_code rtems_device_driver;
> >>
> >> ?
> >>
> >> For me this looks a bit like camouflage.
> >>
> >>
> >> No. It is a use of typedef to make the purpose of the method clear.
> >>
> >> You have nibbled at these for years. There were at least types for
> >> Classic Tasks, ASRs, and TSRs at one point.
> > Yes, the typedefs to void.
> >>
> >> If this is the last one, I'm not going to fight it. This isn't the
> >> hill I am
> >> going to die on.
> > I am not suggesting to remove them although I find these typedefs
> > pretty odd. I just look for some documentation text.
>
> What about this:
>
> /**
>   * @ingroup RTEMSAPIClassicIO
>   *
>   * @brief This type shall be used in device driver entry declarations and
>   *   definitions.
>   *
>   * Device driver entries return an #rtems_status_code status code. This
> type
>   * definition helps to document device driver entries in the source code.
>   */
> typedef rtems_status_code rtems_device_driver;
>

That's more than sufficient.

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

[PATCH 0/1] c-user: Generate I/O Manager documentation

2020-09-29 Thread Sebastian Huber 
This is the first generated documentation of a manager. For the PDF
output please have a look at:

https://ftp.rtems.org/pub/rtems/people/sebh/c-user.pdf

Please review the layout.  I changed the layout to use definition lists
instead of tables.  The benefit of definition lists is that the layout
of longer text paragraphs is much nicer compared to tables (at least for
the PDF output).

Sebastian Huber (1):
  c-user: Generate I/O Manager documentation

 c-user/io/directives.rst   | 550 ++---
 c-user/io/introduction.rst |  37 ++-
 2 files changed, 295 insertions(+), 292 deletions(-)

-- 
2.26.2

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

[PATCH 1/1] c-user: Generate I/O Manager documentation

2020-09-29 Thread Sebastian Huber 
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.

Update #3993.
---
 c-user/io/directives.rst   | 550 ++---
 c-user/io/introduction.rst |  37 ++-
 2 files changed, 295 insertions(+), 292 deletions(-)

diff --git a/c-user/io/directives.rst b/c-user/io/directives.rst
index d3098cb..5ffac5f 100644
--- a/c-user/io/directives.rst
+++ b/c-user/io/directives.rst
@@ -1,421 +1,413 @@
 .. SPDX-License-Identifier: CC-BY-SA-4.0
 
+.. Copyright (C) 2020 embedded brains GmbH (http://www.embedded-brains.de)
 .. Copyright (C) 1988, 2008 On-Line Applications Research Corporation (OAR)
 
+.. _InputOutputInterfaceManagerDirectives:
+
 Directives
 ==
 
-This section details the I/O manager's directives.  A subsection is dedicated
-to each of this manager's directives and describes the calling sequence,
-related constants, usage, and status codes.
-
-.. raw:: latex
-
-   \clearpage
+.. _InterfaceRtemsIoClose:
 
-.. index:: register a device driver
-.. index:: rtems_io_register_driver
+rtems_io_close()
+
 
-.. _rtems_io_register_driver:
-
-IO_REGISTER_DRIVER - Register a device driver
--
+Closes the device specified by the device major and minor numbers.
 
 CALLING SEQUENCE:
 .. code-block:: c
 
-rtems_status_code rtems_io_register_driver(
-rtems_device_major_number   major,
-rtems_driver_address_table *driver_table,
-rtems_device_major_number  *registered_major
+rtems_status_code rtems_io_close(
+  rtems_device_major_number major,
+  rtems_device_minor_number minor,
+  void *argument
 );
 
-DIRECTIVE STATUS CODES:
-.. list-table::
- :class: rtems-table
-
- * - ``RTEMS_SUCCESSFUL``
-   - successfully registered
- * - ``RTEMS_INVALID_ADDRESS``
-   - invalid registered major pointer
- * - ``RTEMS_INVALID_ADDRESS``
-   - invalid driver table
- * - ``RTEMS_INVALID_NUMBER``
-   - invalid major device number
- * - ``RTEMS_TOO_MANY``
-   - no available major device table slot
- * - ``RTEMS_RESOURCE_IN_USE``
-   - major device number entry in use
+DIRECTIVE PARAMETERS:
+major
+This parameter is the major number of the device.
 
-DESCRIPTION:
-This directive attempts to add a new device driver to the Device Driver
-Table. The user can specify a specific major device number via the
-directive's ``major`` parameter, or let the registration routine find the
-next available major device number by specifing a major number of
-``0``. The selected major device number is returned via the
-``registered_major`` directive parameter. The directive automatically
-allocation major device numbers from the highest value down.
+minor
+This parameter is the minor number of the device.
 
-This directive automatically invokes the ``IO_INITIALIZE`` directive if the
-driver address table has an initialization and open entry.
+argument
+This parameter is the argument passed to the device driver close entry.
 
-The directive returns ``RTEMS_TOO_MANY`` if Device Driver Table is full,
-and ``RTEMS_RESOURCE_IN_USE`` if a specific major device number is
-requested and it is already in use.
+DIRECTIVE RETURN VALUES:
+RTEMS_SUCCESSFUL
+The requested operation was successful.
 
-NOTES:
-The Device Driver Table size is specified in the Configuration Table
-condiguration. This needs to be set to maximum size the application
-requires.
+RTEMS_INVALID_NUMBER
+The device major number was invalid.
 
-.. raw:: latex
+Other status codes may be returned by the device driver close entry.
 
-   \clearpage
+DESCRIPTION:
+This directive calls the device driver close entry registered in the Device
+Driver Table for the specified device major number.
 
-.. index:: unregister a device driver
-.. index:: rtems_io_unregister_driver
+NOTES:
+The close entry point is commonly used by device drivers to relinquish
+exclusive access to a device.
 
-.. _rtems_io_unregister_driver:
+.. _InterfaceRtemsIoControl:
 
-IO_UNREGISTER_DRIVER - Unregister a device driver
--
+rtems_io_control()
+--
+
+Controls the device specified by the device major and minor numbers.
 
 CALLING SEQUENCE:
 .. code-block:: c
 
-rtems_status_code rtems_io_unregister_driver(
-rtems_device_major_number   major
+rtems_status_code rtems_io_control(
+  rtems_device_major_number major,
+  rtems_device_minor_number minor,
+  void *argument
 );
 
-DIRECTIVE STATUS CODES:
-.. lis

[PATCH 1/1] rtems: Generate

2020-09-29 Thread Sebastian Huber 
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.
---
 cpukit/include/rtems/io.h | 480 --
 1 file changed, 351 insertions(+), 129 deletions(-)

diff --git a/cpukit/include/rtems/io.h b/cpukit/include/rtems/io.h
index 67364df280..9d0de33c30 100644
--- a/cpukit/include/rtems/io.h
+++ b/cpukit/include/rtems/io.h
@@ -1,24 +1,52 @@
+/* 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) 1989-2008.
- *  On-Line Applications Research Corporation (OAR).
+ * 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.
  *
- *  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.
+ * 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.
+ */
+
+/*
+ * This file was automatically generated.  Do not edit it manually.
+ * Please have a look at
+ *
+ * https://docs.rtems.org/branches/master/eng/req/howto.html
+ *
+ * for information how to maintain and re-generate this file.
  */
 
 #ifndef _RTEMS_IO_H
 #define _RTEMS_IO_H
 
+#include 
 #include 
 
 #ifdef __cplusplus
@@ -26,203 +54,397 @@ extern "C" {
 #endif
 
 /**
- * @defgroup ClassicIO Input/Output
+ * @defgroup RTEMSAPIClassicIO Input/Output Interface Manager
  *
  * @ingroup RTEMSAPIClassic
  *
+ * @brief The Input/Output Interface 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;
 
+/**
+ * @ingroup RTEMSAPIClassicIO
+ *
+ * @brief This integer type represents the minor number of devices.
+ *
+ * The minor number of devices is managed by the device driver.
+ */
 typedef uint32_t rtems_device_minor_number;
 
-typedef rtems_status_code rtems_device_driver;
+/**
+ * @ingroup RTEMSAPIClassicIO
+ *
+ * @brief This integer type represents the major number of devices.
+ *
+ * The major number of a device is determined by rtems_io_register_driver() and
+ * the application configuration (see #CONFIGURE_MAXIMUM_DRIVERS) .
+ */
+typedef uint32_t rtems_device_major_number;
 
-typedef rtems_device_driver (*rtems_device_driver_entry)(
-  rtems_device_major_number,
-  rtems_device_minor_number,
-  void *
-);
+/**
+ * @ingroup RTEMSAPIClassicIO
+ *
+ * @brief This type shall be used in device driver entry declarations and
+ *   definitions.
+ *
+ * Device driver entries return an #rtems_status_code status code. This type
+ * definition helps to document device driver entries in the source code.
+ */
+typedef rtems_status_code rtems_device_driver;
 
+/**
+ * @ingroup RTEMSAPIClassicIO
+ *
+ * @brief This structure contains the device driver entries.
+ *
+ * This structure is used to register a device driver via
+ * rtems_io_register_driver().
+ */
 typedef struct {
+  /**
+   * @brief This member is the device driver initialization entry.
+   *
+   * This entry is called by rtems_io_initialize()
+   */
   rtems_device_driver_entry initia

[PATCH 0/1] rtems: Generate

2020-09-29 Thread Sebastian Huber 
This header file with Doxygen markup contains the documentation
corresponding to:

https://lists.rtems.org/pipermail/devel/2020-September/062395.html

Sebastian Huber (1):
  rtems: Generate 

 cpukit/include/rtems/io.h | 480 --
 1 file changed, 351 insertions(+), 129 deletions(-)

-- 
2.26.2

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

New Build Sweeps

2020-09-29 Thread Joel Sherrill 
Hi

I am starting to do a sweep of all BSPs with various configure options and
build them back to back with autoconf and waf with the same options. I am
just doing a basic sweep now of SMP on/off and Debug on/off and reporting
issues as I spot them.

Overnight a build sweep completed which had test runs which were based on
similar combinations. Others should double check the build@ archives to see
that the duplicate test runs (autoconf followed by waf) did in fact pass
the same.

My intention is to vary more configure options through both build systems
and every BSP but will be building all tests on every variation. Obviously
the build time iwill be high but I hope this will help us build confidence.

Hopefully this will help us move forward.

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

Recent rtems-bsp-builder results

2020-09-29 Thread Joel Sherrill 
Hi

Has anyone run this lately? I got all failures on my sweep over the
weekend. That doesn't match my results by hand where I built and ran tests
on some.

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

Re: Purpose of rtems_device_driver?

2020-09-29 Thread Peter Dufault 


> On Sep 29, 2020, at 10:13 , Joel Sherrill  wrote:
> 
> 
> 
> On Tue, Sep 29, 2020 at 8:54 AM Sebastian Huber 
>  wrote:
> On 29/09/2020 15:47, Sebastian Huber wrote:
> 
> > On 29/09/2020 15:42, Joel Sherrill wrote:
> >
> >>
> >>
> >> On Tue, Sep 29, 2020 at 8:37 AM Sebastian Huber
> >>  >> > wrote:
> >>
> >> Hello,
> >>
> >> I work currently on the documentation of the IO Manager. What is the
> >> purpose of
> >>
> >> typedef rtems_status_code rtems_device_driver;
> >>
> >> ?
> >>
> >> For me this looks a bit like camouflage.
> >>
> >>
> >> No. It is a use of typedef to make the purpose of the method clear.
> >>
> >> You have nibbled at these for years. There were at least types for
> >> Classic Tasks, ASRs, and TSRs at one point.
> > Yes, the typedefs to void.
> >>
> >> If this is the last one, I'm not going to fight it. This isn't the
> >> hill I am
> >> going to die on.
> > I am not suggesting to remove them although I find these typedefs
> > pretty odd. I just look for some documentation text.
> 
> What about this:
> 
> /**
>   * @ingroup RTEMSAPIClassicIO
>   *
>   * @brief This type shall be used in device driver entry declarations and
>   *   definitions.
>   *
>   * Device driver entries return an #rtems_status_code status code. This
> type
>   * definition helps to document device driver entries in the source code.
>   */
> typedef rtems_status_code rtems_device_driver;
> 
> That's more than sufficient.
> 
> Thanks.

This typedef is odd.  Unless I'm missing a fine-point.

If the typedef is, and always will remain, "rtems_status_code" I would not use 
a typedef.

The RTEMS API documentation is moving to Doxygen (and more formally than that 
given Sebastian's ESA work). Using a typedef to indicate a function is part of 
a device driver as "documentation" is not a good idea.

When I've thought I needed a special return code in the past I've made the 
return code a "struct" so that it can't be used interchangeably with other 
return codes, even with casting, and so that you need to be *sure* you really 
want such a special return type. This probably pre-dates enabling aggressive 
warnings.

I haven't done this recently.  Recently I've assumed that:
- Status codes are an integral type;
- Status codes of 0 always mean success.

Trying to pretend you need to compare a return to a special "success" #define 
that is 0 is pointless and error prone now-a-days IMHO.

If I really wanted a return code that was special I'd do something like:

typedef struct {
  rtems_status_code status; /* Error return. */
  int unused;   /* Unused */
} rtems_device_driver;

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: Purpose of rtems_device_driver?

2020-09-29 Thread Joel Sherrill 
I'm not disagreeing with you at all Peter. This is definitely history and a
"grep -r _routine | grep typedef" will show a few other cases where this
pattern still exists. In at least one, it is internal and deprecated.

You are right. This is from the earliest days of RTEMS. I looked in the
scanned RTEID and ORKID documents and can't fine the IO manager. I swear it
came from there but I did find a pSOS+ manual online and their interface
was so bare, it did not use any typedef at all. It even mentioned CPU
architecture specific differences. 

If we want to deprecate it, I'm ok with that. But we should put all of
these kind of typedefs. on the way to the dustbin.

It is definitely used enough where eliminating it will take scripting.

 grep -r "rtems_device_driver " . 2>/dev/null | wc -l
710

That doesn't count timer_service_routine, the one for signals, etc.

I'm not opposed and now is the time if there is consensus. I have reached
the point where I acknowledge the long history and mostly am concerned
about how changes impact user code more than the idea of change itself.

--joel

On Tue, Sep 29, 2020 at 1:01 PM Peter Dufault  wrote:

>
>
> > On Sep 29, 2020, at 10:13 , Joel Sherrill  wrote:
> >
> >
> >
> > On Tue, Sep 29, 2020 at 8:54 AM Sebastian Huber <
> sebastian.hu...@embedded-brains.de> wrote:
> > On 29/09/2020 15:47, Sebastian Huber wrote:
> >
> > > On 29/09/2020 15:42, Joel Sherrill wrote:
> > >
> > >>
> > >>
> > >> On Tue, Sep 29, 2020 at 8:37 AM Sebastian Huber
> > >>  > >> > wrote:
> > >>
> > >> Hello,
> > >>
> > >> I work currently on the documentation of the IO Manager. What is
> the
> > >> purpose of
> > >>
> > >> typedef rtems_status_code rtems_device_driver;
> > >>
> > >> ?
> > >>
> > >> For me this looks a bit like camouflage.
> > >>
> > >>
> > >> No. It is a use of typedef to make the purpose of the method clear.
> > >>
> > >> You have nibbled at these for years. There were at least types for
> > >> Classic Tasks, ASRs, and TSRs at one point.
> > > Yes, the typedefs to void.
> > >>
> > >> If this is the last one, I'm not going to fight it. This isn't the
> > >> hill I am
> > >> going to die on.
> > > I am not suggesting to remove them although I find these typedefs
> > > pretty odd. I just look for some documentation text.
> >
> > What about this:
> >
> > /**
> >   * @ingroup RTEMSAPIClassicIO
> >   *
> >   * @brief This type shall be used in device driver entry declarations
> and
> >   *   definitions.
> >   *
> >   * Device driver entries return an #rtems_status_code status code. This
> > type
> >   * definition helps to document device driver entries in the source
> code.
> >   */
> > typedef rtems_status_code rtems_device_driver;
> >
> > That's more than sufficient.
> >
> > Thanks.
>
> This typedef is odd.  Unless I'm missing a fine-point.
>
> If the typedef is, and always will remain, "rtems_status_code" I would not
> use a typedef.
>
> The RTEMS API documentation is moving to Doxygen (and more formally than
> that given Sebastian's ESA work). Using a typedef to indicate a function is
> part of a device driver as "documentation" is not a good idea.
>
> When I've thought I needed a special return code in the past I've made the
> return code a "struct" so that it can't be used interchangeably with other
> return codes, even with casting, and so that you need to be *sure* you
> really want such a special return type. This probably pre-dates enabling
> aggressive warnings.
>
> I haven't done this recently.  Recently I've assumed that:
> - Status codes are an integral type;
> - Status codes of 0 always mean success.
>
> Trying to pretend you need to compare a return to a special "success"
> #define that is 0 is pointless and error prone now-a-days IMHO.
>
> If I really wanted a return code that was special I'd do something like:
>
> typedef struct {
>   rtems_status_code status; /* Error return. */
>   int unused;   /* Unused */
> } rtems_device_driver;
>
> 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

Re: Purpose of rtems_device_driver?

2020-09-29 Thread dufault 
I wasn't thinking about user code, I was thinking about the RTEMS source code 
and that the construct should go away. The typedef should be gotten rid of in a 
way that supports user code for a release or so.

> On Sep 29, 2020, at 15:34 , Joel Sherrill  wrote:
> 
> I'm not disagreeing with you at all Peter. This is definitely history and a 
> "grep -r _routine | grep typedef" will show a few other cases where this 
> pattern still exists. In at least one, it is internal and deprecated.
> 
> You are right. This is from the earliest days of RTEMS. I looked in the 
> scanned RTEID and ORKID documents and can't fine the IO manager. I swear it 
> came from there but I did find a pSOS+ manual online and their interface was 
> so bare, it did not use any typedef at all. It even mentioned CPU 
> architecture specific differences. 
> 
> If we want to deprecate it, I'm ok with that. But we should put all of these 
> kind of typedefs. on the way to the dustbin.
> 
> It is definitely used enough where eliminating it will take scripting.
> 
>  grep -r "rtems_device_driver " . 2>/dev/null | wc -l
> 710
> 
> That doesn't count timer_service_routine, the one for signals, etc.
> 
> I'm not opposed and now is the time if there is consensus. I have reached the 
> point where I acknowledge the long history and mostly am concerned about how 
> changes impact user code more than the idea of change itself.
> 
> --joel
> 
> On Tue, Sep 29, 2020 at 1:01 PM Peter Dufault  wrote:
> 
> 
> > On Sep 29, 2020, at 10:13 , Joel Sherrill  wrote:
> >
> >
> >
> > On Tue, Sep 29, 2020 at 8:54 AM Sebastian Huber 
> >  wrote:
> > On 29/09/2020 15:47, Sebastian Huber wrote:
> >
> > > On 29/09/2020 15:42, Joel Sherrill wrote:
> > >
> > >>
> > >>
> > >> On Tue, Sep 29, 2020 at 8:37 AM Sebastian Huber
> > >>  > >> > wrote:
> > >>
> > >> Hello,
> > >>
> > >> I work currently on the documentation of the IO Manager. What is the
> > >> purpose of
> > >>
> > >> typedef rtems_status_code rtems_device_driver;
> > >>
> > >> ?
> > >>
> > >> For me this looks a bit like camouflage.
> > >>
> > >>
> > >> No. It is a use of typedef to make the purpose of the method clear.
> > >>
> > >> You have nibbled at these for years. There were at least types for
> > >> Classic Tasks, ASRs, and TSRs at one point.
> > > Yes, the typedefs to void.
> > >>
> > >> If this is the last one, I'm not going to fight it. This isn't the
> > >> hill I am
> > >> going to die on.
> > > I am not suggesting to remove them although I find these typedefs
> > > pretty odd. I just look for some documentation text.
> >
> > What about this:
> >
> > /**
> >   * @ingroup RTEMSAPIClassicIO
> >   *
> >   * @brief This type shall be used in device driver entry declarations and
> >   *   definitions.
> >   *
> >   * Device driver entries return an #rtems_status_code status code. This
> > type
> >   * definition helps to document device driver entries in the source code.
> >   */
> > typedef rtems_status_code rtems_device_driver;
> >
> > That's more than sufficient.
> >
> > Thanks.
> 
> This typedef is odd.  Unless I'm missing a fine-point.
> 
> If the typedef is, and always will remain, "rtems_status_code" I would not 
> use a typedef.
> 
> The RTEMS API documentation is moving to Doxygen (and more formally than that 
> given Sebastian's ESA work). Using a typedef to indicate a function is part 
> of a device driver as "documentation" is not a good idea.
> 
> When I've thought I needed a special return code in the past I've made the 
> return code a "struct" so that it can't be used interchangeably with other 
> return codes, even with casting, and so that you need to be *sure* you really 
> want such a special return type. This probably pre-dates enabling aggressive 
> warnings.
> 
> I haven't done this recently.  Recently I've assumed that:
> - Status codes are an integral type;
> - Status codes of 0 always mean success.
> 
> Trying to pretend you need to compare a return to a special "success" #define 
> that is 0 is pointless and error prone now-a-days IMHO.
> 
> If I really wanted a return code that was special I'd do something like:
> 
> typedef struct {
>   rtems_status_code status; /* Error return. */
>   int unused;   /* Unused */
> } rtems_device_driver;
> 
> 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.
> 

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 3/8] bsps: Break out AArch32 portions of GPT driver

2020-09-29 Thread Kinsey Moore 
-Original Message-
From: Sebastian Huber  
Sent: Tuesday, September 29, 2020 06:22
To: Kinsey Moore ; devel@rtems.org
Subject: Re: [PATCH v2 3/8] bsps: Break out AArch32 portions of GPT driver

On 28/09/2020 17:24, Kinsey Moore wrote:

>   create mode 100644 bsps/include/bsp/clock-arm-generic-timer.h
>   rename bsps/{arm/shared/clock/clock-generic-timer.c => 
> shared/clock/clock-arm-generic-timer.c} (71%)

I would add it as:

bsps/shared/dev/clock/arm-generic-timer.c

bsps/include/dev/clock/arm-generic-timer.h

[] 
Your comment on the pl011 adjustments specified bsps/shared/include/dev while 
this comment mentions bsps/include/dev. Which is the preferred location?

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

Build Sweeps Before Full Switch To Waf

2020-09-29 Thread Joel Sherrill 
Hi

Over the weekend, I think the modifications to my existing build sweeper
reached the point where test results for BSPs on simulators were reported
got an autoconf build followed by a waf build of the same configuration.
The results should be the same.

I have made some headway on a special build sweep for the autoconf to waf
switch. I am currently building every BSP tests on and with debug on/off
and SMP on/off using both autoconf and waf. I have reported some failures
on ARM.  My intention is to see a sweep with these four being toggled,
report problems, and then augment the script to toggle every configure
option.

I updated https://devel.rtems.org/wiki/Release/6/Waf%20BSP%20Checklist to
include this.

I expect this will result in some discussions and the lengthy build sweeps
could easily push us past the goal of early November. We need to see the
issues resolved and both build systems have equivalent results.

I have not figured out how to include the legacy stack in this. It may
simply be a special pass focused on a single BSP per architecture or the
BSPs which it should work with.

Anyway, I plan to be building a lot and reporting a lot. Unless issues are
addressed and the results match, I am going to be against a switch over.

I am not opposed to the switch over. I just want to ensure it is tested as
best we can and build time is cheap except for the time part. :)

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

Re: Build Sweeps Before Full Switch To Waf

2020-09-29 Thread Chris Johns 
On 30/9/20 10:22 am, Joel Sherrill wrote:
> I updated https://devel.rtems.org/wiki/Release/6/Waf%20BSP%20Checklist to
> include this.

I have added a "Builds Match" column to help track this.

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

Re: [PATCH v2 6/8] score: Add AArch64 port

2020-09-29 Thread Chris Johns 
On 29/9/20 9:37 pm, Sebastian Huber wrote:
> On 28/09/2020 17:24, Kinsey Moore wrote:
> 
>> +/* TODO(kmoore) The current implementation here assumes that SP is not
>> misaligned */
> Maybe add a ticket for this TODO and reference it in the comment.
>> +    .macro    JUMP_HANDLER
>> +    mov x0, #0x7f    /* mask to use in BIC, lower 7 bits */
>> +    bic x0,    lr,    x0    /* lr contains PC, mask off to the base of
>> the current vector */
>> +    ldr x0,    [x0,    #0x78]    /* load address from the last word in
>> the vector */
>> +    blr x0    /* branch and link to address in x0, no reason to
>> save current LR since it has already been saved and current contents are 
>> junk */
>> +    ldp x0,    lr,    [sp],    #16    /* pop x0,lr from stack */
>> +    eret    /* return from exception */
> Some lines are longer than 79 characters. I spotted also // comments. I have
> nothing against // comments in general, but before we introduce them, it would
> be good to update the coding style.

It seems Kinsey wrote the code with C comments so lets say use just C comments 
...

https://developer.arm.com/documentation/100933/0100/AArch64-exception-vector-table

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

Re: [PATCH v2 3/8] bsps: Break out AArch32 portions of GPT driver

2020-09-29 Thread Sebastian Huber 



On 30/09/2020 02:16, Kinsey Moore wrote:

-Original Message-
From: Sebastian Huber 
Sent: Tuesday, September 29, 2020 06:22
To: Kinsey Moore ; devel@rtems.org
Subject: Re: [PATCH v2 3/8] bsps: Break out AArch32 portions of GPT driver

On 28/09/2020 17:24, Kinsey Moore wrote:


   create mode 100644 bsps/include/bsp/clock-arm-generic-timer.h
   rename bsps/{arm/shared/clock/clock-generic-timer.c => 
shared/clock/clock-arm-generic-timer.c} (71%)

I would add it as:

bsps/shared/dev/clock/arm-generic-timer.c

bsps/include/dev/clock/arm-generic-timer.h

[]
Your comment on the pl011 adjustments specified bsps/shared/include/dev while 
this comment mentions bsps/include/dev. Which is the preferred location?


Sorry, the bsps/shared/include/dev was a typo. The shared header files 
belong to bsps/include.


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

Re: [PATCH] tests: Add and use

2020-09-29 Thread Chris Johns 
On 29/9/20 11:31 pm, Sebastian Huber wrote:
> Add the build option RTEMS_TEST_VERBOSITY to control the verbosity of
> test suites using the RTEMS test framework.

Does this create another build variant?

Why would I play with this option?

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

Re: [PATCH] tests: Add and use

2020-09-29 Thread Sebastian Huber 

On 30/09/2020 07:52, Chris Johns wrote:


On 29/9/20 11:31 pm, Sebastian Huber wrote:

Add the build option RTEMS_TEST_VERBOSITY to control the verbosity of
test suites using the RTEMS test framework.

Does this create another build variant?

Each build option creates variants.


Why would I play with this option?
For normal tests runs you can use a verbosity of normal. If you need a 
more detailed output, then you can set it to verbose. For example, in 
case a regression ocurred.

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

Re: [PATCH] tests: Add and use

2020-09-29 Thread Chris Johns 



On 30/9/20 3:55 pm, Sebastian Huber wrote:
> On 30/09/2020 07:52, Chris Johns wrote:
> 
>> On 29/9/20 11:31 pm, Sebastian Huber wrote:
>>> Add the build option RTEMS_TEST_VERBOSITY to control the verbosity of
>>> test suites using the RTEMS test framework.
>> Does this create another build variant?
> Each build option creates variants.

Yes I am rather aware of this. I am wondering if we need to capture in the spec
files which options needs to be regression tested?

>> Why would I play with this option?
> For normal tests runs you can use a verbosity of normal. If you need a more
> detailed output, then you can set it to verbose. For example, in case a
> regression ocurred.

This makes sense. Has this been captured somewhere?

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

Re: Purpose of rtems_device_driver?

2020-09-29 Thread Sebastian Huber 

Hello Peter,

On 29/09/2020 20:01, Peter Dufault wrote:

On Sep 29, 2020, at 10:13 , Joel Sherrill  wrote:



On Tue, Sep 29, 2020 at 8:54 AM Sebastian 
Huber  wrote:
On 29/09/2020 15:47, Sebastian Huber wrote:


On 29/09/2020 15:42, Joel Sherrill wrote:


On Tue, Sep 29, 2020 at 8:37 AM Sebastian Huber
mailto:sebastian.hu...@embedded-brains.de>> wrote:

 Hello,

 I work currently on the documentation of the IO Manager. What is the
 purpose of

 typedef rtems_status_code rtems_device_driver;

 ?

 For me this looks a bit like camouflage.


No. It is a use of typedef to make the purpose of the method clear.

You have nibbled at these for years. There were at least types for
Classic Tasks, ASRs, and TSRs at one point.

Yes, the typedefs to void.

If this is the last one, I'm not going to fight it. This isn't the
hill I am
going to die on.

I am not suggesting to remove them although I find these typedefs
pretty odd. I just look for some documentation text.

What about this:

/**
   * @ingroup RTEMSAPIClassicIO
   *
   * @brief This type shall be used in device driver entry declarations and
   *   definitions.
   *
   * Device driver entries return an #rtems_status_code status code. This
type
   * definition helps to document device driver entries in the source code.
   */
typedef rtems_status_code rtems_device_driver;

That's more than sufficient.

Thanks.

This typedef is odd.  Unless I'm missing a fine-point.

If the typedef is, and always will remain, "rtems_status_code" I would not use 
a typedef.


I don't want to change the API, I just want to document it. However, I 
am not sure if we should advertise the use of these typedefs in 
application code:


typedef rtems_status_code rtems_device_driver;

typedef void rtems_task;

typedef void rtems_timer_service_routine;

typedef void rtems_asr;

If you consistently use these types, then for example you can grep for 
"\" and find all task entry functions. I guess some people 
like this, other don't like it.




The RTEMS API documentation is moving to Doxygen (and more formally than that given 
Sebastian's ESA work). Using a typedef to indicate a function is part of a device driver 
as "documentation" is not a good idea.


The API documentation is not really moving to Doxygen. It moves to 
specification items after consolidation and then it moves back to Doxygen and 
the manuals. A common data set and the generation through a script ensures that 
the documentation in both parts is consistent.

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

[PATCH v2] tests: Add and use

2020-09-29 Thread Sebastian Huber 
Add the build option RTEMS_TEST_VERBOSITY to control the verbosity of
test suites using the RTEMS test framework.
---
v2:

Improve option comment.

 spec/build/testsuites/grp.yml |  2 ++
 spec/build/testsuites/optverbosity.yml| 31 +++
 spec/build/testsuites/testopts.yml| 13 ++
 testsuites/smptests/smpmulticast01/init.c |  3 ++-
 testsuites/validation/ts-validation-0.c   |  3 ++-
 5 files changed, 50 insertions(+), 2 deletions(-)
 create mode 100644 spec/build/testsuites/optverbosity.yml
 create mode 100644 spec/build/testsuites/testopts.yml

diff --git a/spec/build/testsuites/grp.yml b/spec/build/testsuites/grp.yml
index 5c6457f06d..fa2bad1016 100644
--- a/spec/build/testsuites/grp.yml
+++ b/spec/build/testsuites/grp.yml
@@ -62,6 +62,8 @@ links:
   uid: tmtests/grp
 - role: build-dependency
   uid: validation/grp
+- role: build-dependency
+  uid: testopts
 type: build
 use-after:
 - rtemscpu
diff --git a/spec/build/testsuites/optverbosity.yml 
b/spec/build/testsuites/optverbosity.yml
new file mode 100644
index 00..2b383ae55d
--- /dev/null
+++ b/spec/build/testsuites/optverbosity.yml
@@ -0,0 +1,31 @@
+SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
+actions:
+- get-string: null
+- script: |
+verbosities = {
+"Verbose": "T_VERBOSE",
+"Normal": "T_NORMAL",
+"Quiet": "T_QUIET",
+}
+name = self.data["name"]
+try:
+conf.define(name, verbosities[value], quote=False)
+except KeyError:
+conf.fatal("The value of {} shall be one of {}".format(
+   name, verbosities.keys()))
+build-type: option
+copyrights:
+- Copyright (C) 2020 embedded brains GmbH (http://www.embedded-brains.de)
+default: Normal
+default-by-variant: []
+description: |
+  Sets the test verbosity.  Valid values are "Verbose", "Normal", and "Quiet".
+  For normal tests runs you can use a verbosity of "Normal".  If you need a
+  more detailed output, then you can set it to "Verbose".  For example, in case
+  a regression ocurred.  Reducing the verbosity level can significantly reduce
+  the test duration especially on targets with a slow serial output device.
+enabled-by: true
+format: '{}'
+links: []
+name: RTEMS_TEST_VERBOSITY
+type: build
diff --git a/spec/build/testsuites/testopts.yml 
b/spec/build/testsuites/testopts.yml
new file mode 100644
index 00..8b6ab38f56
--- /dev/null
+++ b/spec/build/testsuites/testopts.yml
@@ -0,0 +1,13 @@
+SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
+build-type: config-header
+copyrights:
+- Copyright (C) 2020 embedded brains GmbH (http://www.embedded-brains.de)
+enabled-by: true
+guard: _RTEMS_TESTOPTS_H
+include-headers: []
+install-path: ${BSP_INCLUDEDIR}/rtems
+links:
+- role: build-dependency
+  uid: optverbosity
+target: cpukit/include/rtems/testopts.h
+type: build
diff --git a/testsuites/smptests/smpmulticast01/init.c 
b/testsuites/smptests/smpmulticast01/init.c
index f5ed70952a..3d2412427c 100644
--- a/testsuites/smptests/smpmulticast01/init.c
+++ b/testsuites/smptests/smpmulticast01/init.c
@@ -34,6 +34,7 @@
 #include 
 
 #include 
+#include 
 #include 
 
 #define CPU_COUNT 32
@@ -43,7 +44,7 @@ const char rtems_test_name[] = "SMPMULTICAST 1";
 static const T_config config = {
   .name = "SMPMultiCast",
   .putchar = T_putchar_default,
-  .verbosity = T_VERBOSE,
+  .verbosity = RTEMS_TEST_VERBOSITY,
   .now = T_now_clock
 };
 
diff --git a/testsuites/validation/ts-validation-0.c 
b/testsuites/validation/ts-validation-0.c
index 3e60fb6ab8..0d641637ee 100644
--- a/testsuites/validation/ts-validation-0.c
+++ b/testsuites/validation/ts-validation-0.c
@@ -49,6 +49,7 @@
 #include 
 
 #include 
+#include 
 
 /**
  * @defgroup RTEMSTestSuiteTestsuitesValidation0 spec:/testsuites/validation-0
@@ -88,7 +89,7 @@ static const T_config test_config = {
   .buf = buffer,
   .buf_size = sizeof( buffer ),
   .putchar = rtems_put_char,
-  .verbosity = T_VERBOSE,
+  .verbosity = RTEMS_TEST_VERBOSITY,
   .now = T_now_clock,
   .action_count = T_ARRAY_SIZE( actions ),
   .actions = actions
-- 
2.26.2

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

Re: [PATCH v2] tests: Add and use

2020-09-29 Thread Chris Johns 
On 30/9/20 4:09 pm, Sebastian Huber wrote:
> +description: |
> +  Sets the test verbosity.  Valid values are "Verbose", "Normal", and 
> "Quiet".
> +  For normal tests runs you can use a verbosity of "Normal".  If you need a
> +  more detailed output, then you can set it to "Verbose".  For example, in 
> case
> +  a regression ocurred.  Reducing the verbosity level can significantly 
> reduce
> +  the test duration especially on targets with a slow serial output device.

Thanks.

Should this also state the required test output is not effected by this setting?
For example 'Quiet' will not suppress the BEGIN and END test banners. When
viewed in that context the setting becomes informational only.

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

[PATCH v3] tests: Add and use

2020-09-29 Thread Sebastian Huber 
Add the build option RTEMS_TEST_VERBOSITY to control the verbosity of
test suites using the RTEMS Test Framework.
---

v2 and v3:

Improve option comment.

 spec/build/testsuites/grp.yml |  2 ++
 spec/build/testsuites/optverbosity.yml| 34 +++
 spec/build/testsuites/testopts.yml| 13 +
 testsuites/smptests/smpmulticast01/init.c |  3 +-
 testsuites/validation/ts-validation-0.c   |  3 +-
 5 files changed, 53 insertions(+), 2 deletions(-)
 create mode 100644 spec/build/testsuites/optverbosity.yml
 create mode 100644 spec/build/testsuites/testopts.yml

diff --git a/spec/build/testsuites/grp.yml b/spec/build/testsuites/grp.yml
index 5c6457f06d..fa2bad1016 100644
--- a/spec/build/testsuites/grp.yml
+++ b/spec/build/testsuites/grp.yml
@@ -62,6 +62,8 @@ links:
   uid: tmtests/grp
 - role: build-dependency
   uid: validation/grp
+- role: build-dependency
+  uid: testopts
 type: build
 use-after:
 - rtemscpu
diff --git a/spec/build/testsuites/optverbosity.yml 
b/spec/build/testsuites/optverbosity.yml
new file mode 100644
index 00..0822caf3c7
--- /dev/null
+++ b/spec/build/testsuites/optverbosity.yml
@@ -0,0 +1,34 @@
+SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
+actions:
+- get-string: null
+- script: |
+verbosities = {
+"Verbose": "T_VERBOSE",
+"Normal": "T_NORMAL",
+"Quiet": "T_QUIET",
+}
+name = self.data["name"]
+try:
+conf.define(name, verbosities[value], quote=False)
+except KeyError:
+conf.fatal("The value of {} shall be one of {}".format(
+   name, verbosities.keys()))
+build-type: option
+copyrights:
+- Copyright (C) 2020 embedded brains GmbH (http://www.embedded-brains.de)
+default: Normal
+default-by-variant: []
+description: |
+  Sets the test verbosity of the RTEMS Test Framework.  Valid values are
+  "Verbose", "Normal", and "Quiet".  For normal tests runs you can use a
+  verbosity of "Normal".  If you need a more detailed output, then you can set
+  it to "Verbose".  For example, in case a regression ocurred.  Reducing the
+  verbosity level can significantly reduce the test duration especially on
+  targets with a slow serial output device.  All verbosity levels produce
+  enough output to notice failed test cases.  In particular, the begin and end
+  of test information is not affected by the verbosity level.
+enabled-by: true
+format: '{}'
+links: []
+name: RTEMS_TEST_VERBOSITY
+type: build
diff --git a/spec/build/testsuites/testopts.yml 
b/spec/build/testsuites/testopts.yml
new file mode 100644
index 00..8b6ab38f56
--- /dev/null
+++ b/spec/build/testsuites/testopts.yml
@@ -0,0 +1,13 @@
+SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
+build-type: config-header
+copyrights:
+- Copyright (C) 2020 embedded brains GmbH (http://www.embedded-brains.de)
+enabled-by: true
+guard: _RTEMS_TESTOPTS_H
+include-headers: []
+install-path: ${BSP_INCLUDEDIR}/rtems
+links:
+- role: build-dependency
+  uid: optverbosity
+target: cpukit/include/rtems/testopts.h
+type: build
diff --git a/testsuites/smptests/smpmulticast01/init.c 
b/testsuites/smptests/smpmulticast01/init.c
index f5ed70952a..3d2412427c 100644
--- a/testsuites/smptests/smpmulticast01/init.c
+++ b/testsuites/smptests/smpmulticast01/init.c
@@ -34,6 +34,7 @@
 #include 
 
 #include 
+#include 
 #include 
 
 #define CPU_COUNT 32
@@ -43,7 +44,7 @@ const char rtems_test_name[] = "SMPMULTICAST 1";
 static const T_config config = {
   .name = "SMPMultiCast",
   .putchar = T_putchar_default,
-  .verbosity = T_VERBOSE,
+  .verbosity = RTEMS_TEST_VERBOSITY,
   .now = T_now_clock
 };
 
diff --git a/testsuites/validation/ts-validation-0.c 
b/testsuites/validation/ts-validation-0.c
index 3e60fb6ab8..0d641637ee 100644
--- a/testsuites/validation/ts-validation-0.c
+++ b/testsuites/validation/ts-validation-0.c
@@ -49,6 +49,7 @@
 #include 
 
 #include 
+#include 
 
 /**
  * @defgroup RTEMSTestSuiteTestsuitesValidation0 spec:/testsuites/validation-0
@@ -88,7 +89,7 @@ static const T_config test_config = {
   .buf = buffer,
   .buf_size = sizeof( buffer ),
   .putchar = rtems_put_char,
-  .verbosity = T_VERBOSE,
+  .verbosity = RTEMS_TEST_VERBOSITY,
   .now = T_now_clock,
   .action_count = T_ARRAY_SIZE( actions ),
   .actions = actions
-- 
2.26.2

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