Old network stack and aarch64

[Sebastian Huber]

Hello,

building the old network stack for aarch64 fails with:

cpukit/librpc/src/xdr/xdr_float.c:121:2: error: #error "xdr_float.c: 
unknown CPU"

  121 | #error "xdr_float.c: unknown CPU"

Should we enable RTEMS_NETWORKING more selectively similar to RTEMS_SMP 
and RTEMS_MULTIPROCESSING?


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

Re: [PATCH] rtems: Improve RTEMS_NO_RETURN attribute

[Sebastian Huber]

On 06/10/2020 08:06, Sebastian Huber wrote:


Provide RTEMS_NO_RETURN also in case RTEMS_DEBUG is defined to prevent errors
like this:

error: no return statement in function returning non-void [-Werror=return-type]

Use C11 and C++11 standard means to declare a no-return function.

Close #4122.
Sorry, the main part of the patch was missing from the commit. I send a 
v2 patch.

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

[PATCH v2] rtems: Improve RTEMS_NO_RETURN attribute

[Sebastian Huber]

Provide RTEMS_NO_RETURN also in case RTEMS_DEBUG is defined to prevent errors
like this:

error: no return statement in function returning non-void [-Werror=return-type]

Use C11 and C++11 standard means to declare a no-return function.

Close #4122.
---
 bsps/include/bsp/bootcard.h| 2 +-
 bsps/powerpc/qoriq/include/bsp.h   | 6 +++---
 bsps/sparc/leon3/include/leon.h| 2 +-
 cpukit/include/rtems/fatal.h   | 6 ++
 cpukit/include/rtems/init.h| 7 ++-
 cpukit/include/rtems/rtems/tasks.h | 2 +-
 cpukit/include/rtems/score/assert.h| 3 ---
 cpukit/include/rtems/score/basedefs.h  | 8 +---
 cpukit/include/rtems/score/interr.h| 6 +++---
 cpukit/include/rtems/score/smpimpl.h   | 4 ++--
 cpukit/include/rtems/score/threadimpl.h| 6 +++---
 cpukit/include/rtems/test-info.h   | 2 +-
 cpukit/score/cpu/aarch64/include/rtems/score/cpu.h | 3 +--
 cpukit/score/cpu/arm/include/rtems/score/cpu.h | 6 ++
 cpukit/score/cpu/bfin/include/rtems/score/cpu.h| 4 +---
 cpukit/score/cpu/i386/include/rtems/score/cpu.h| 7 ++-
 cpukit/score/cpu/lm32/include/rtems/score/cpu.h| 4 +---
 cpukit/score/cpu/m68k/include/rtems/score/cpu.h| 4 ++--
 cpukit/score/cpu/mips/include/rtems/score/cpu.h| 4 +---
 cpukit/score/cpu/moxie/include/rtems/score/cpu.h   | 4 +---
 cpukit/score/cpu/nios2/include/rtems/score/cpu.h   | 7 ++-
 cpukit/score/cpu/no_cpu/include/rtems/score/cpu.h  | 4 +---
 cpukit/score/cpu/or1k/include/rtems/score/cpu.h| 4 +---
 cpukit/score/cpu/powerpc/include/rtems/score/cpu.h | 4 +---
 cpukit/score/cpu/riscv/include/rtems/score/cpu.h   | 6 ++
 cpukit/score/cpu/sh/include/rtems/score/cpu.h  | 4 +---
 cpukit/score/cpu/sparc/include/rtems/score/cpu.h   | 7 ++-
 cpukit/score/cpu/sparc/include/rtems/score/sparc.h | 6 --
 cpukit/score/cpu/sparc64/include/rtems/score/cpu.h | 4 +---
 cpukit/score/cpu/v850/include/rtems/score/cpu.h| 4 +---
 cpukit/score/cpu/x86_64/include/rtems/score/cpu.h  | 4 +---
 31 files changed, 52 insertions(+), 92 deletions(-)

diff --git a/bsps/include/bsp/bootcard.h b/bsps/include/bsp/bootcard.h
index e3eed8da46..0277dd8439 100644
--- a/bsps/include/bsp/bootcard.h
+++ b/bsps/include/bsp/bootcard.h
@@ -68,7 +68,7 @@ void bsp_reset(void);
  * This style of initialization ensures that the C++ global constructors are
  * executed after RTEMS is initialized.
  */
-void boot_card(const char *cmdline) RTEMS_NO_RETURN;
+RTEMS_NO_RETURN void boot_card(const char *cmdline);
 
 struct Per_CPU_Control;
 
diff --git a/bsps/powerpc/qoriq/include/bsp.h b/bsps/powerpc/qoriq/include/bsp.h
index 1f5ca7f35d..75bf15cefb 100644
--- a/bsps/powerpc/qoriq/include/bsp.h
+++ b/bsps/powerpc/qoriq/include/bsp.h
@@ -88,7 +88,7 @@ int qoriq_if_intercom_attach_detach(
   );
 #endif
 
-void bsp_restart(void *addr) RTEMS_NO_RETURN;
+RTEMS_NO_RETURN void bsp_restart(void *addr);
 
 void *bsp_idle_thread( uintptr_t ignored );
 #define BSP_IDLE_TASK_BODY bsp_idle_thread
@@ -119,9 +119,9 @@ struct Per_CPU_Control;
 
 void qoriq_start_thread(struct Per_CPU_Control *);
 
-void qoriq_restart_secondary_processor(
+RTEMS_NO_RETURN void qoriq_restart_secondary_processor(
   const qoriq_start_spin_table *spin_table
-) RTEMS_NO_RETURN;
+);
 
 void qoriq_initialize_exceptions(void *interrupt_stack_begin);
 
diff --git a/bsps/sparc/leon3/include/leon.h b/bsps/sparc/leon3/include/leon.h
index afe0d91ca4..85e5904305 100644
--- a/bsps/sparc/leon3/include/leon.h
+++ b/bsps/sparc/leon3/include/leon.h
@@ -396,7 +396,7 @@ extern unsigned int leon3_timer_prescaler;
 /* GRLIB extended IRQ controller register */
 void leon3_ext_irq_init(void);
 
-void leon3_power_down_loop(void) RTEMS_NO_RETURN;
+RTEMS_NO_RETURN void leon3_power_down_loop(void);
 
 static inline uint32_t leon3_get_cpu_count(
   volatile struct irqmp_regs *irqmp
diff --git a/cpukit/include/rtems/fatal.h b/cpukit/include/rtems/fatal.h
index 3fc6a89a78..228e7462e0 100644
--- a/cpukit/include/rtems/fatal.h
+++ b/cpukit/include/rtems/fatal.h
@@ -16,7 +16,7 @@
 #ifndef _RTEMS_FATAL_H
 #define _RTEMS_FATAL_H
 
-#include  /* RTEMS_NO_RETURN */
+#include 
 #include 
 
 #ifdef __cplusplus
@@ -68,9 +68,7 @@ static inline void rtems_exception_frame_print(
  *
  * @see _Terminate().
  */
-void rtems_fatal_error_occurred(
-  uint32_t   the_error
-) RTEMS_NO_RETURN;
+RTEMS_NO_RETURN void rtems_fatal_error_occurred( uint32_t the_error );
 
 /**
  * @brief Terminates the system.
diff --git a/cpukit/include/rtems/init.h b/cpukit/include/rtems/init.h
index 86b1408d64..552017f0de 100644
--- a/cpukit/include/rtems/init.h
+++ b/cpukit/include/rtems/init.h
@@ -46,8 +46,7 @@ extern "C" {
  *
  * This directive does not return.
  */
-void rtems_initialize_executive(void)
-  RTEMS_NO_RETURN;
+RTEMS_NO_RETURN void rtems_initialize_executive( void );
 
 /**
  * @brief

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

[Sebastian Huber]

On 05/10/2020 18:10, Gedare Bloom wrote:


+.. Generated from spec:/rtems/io/if/unregister-driver
+
+* :ref:`InterfaceRtemsIoUnregisterDriver` - Removes a device driver specified
+  by the device major number from the Device Driver Table.

In the HTML, there is an extra line spacing between list elements.
Probably because there are two blank lines around the comment, while
the latex backend will merge those. I'd try removing the blank line
between the comment "Generated from" and the generated content.

Thanks for spotting this. It seems the HTML output doesn't like the 
comments at all. I will add a comment block before the list.

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

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

[Sebastian Huber]

On 05/10/2020 18:10, Gedare Bloom wrote:


On Mon, Oct 5, 2020 at 8:40 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.

Update #3993.
---
v2:

* Add comments to mention the specification items which produced a
   content block.

* Preserve original directive order.

* Re-order sections so that the description is between the calling
   sequence and the return values.

* Use .. rubric instead of nested definition lists to fix the vertical
   spacing.

* Add custom document index entries.

Generated PDF:

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

Generated HTML:

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


I think this is really quite a great start to the automatic
generation. I have just a couple of comments.


  c-user/io/directives.rst   | 726 +
  c-user/io/introduction.rst |  64 +++-
  2 files changed, 472 insertions(+), 318 deletions(-)

diff --git a/c-user/io/directives.rst b/c-user/io/directives.rst
index d3098cb..8bf5aea 100644
--- a/c-user/io/directives.rst
+++ b/c-user/io/directives.rst
@@ -1,421 +1,537 @@
  .. 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)

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

"information about how"
"regenerate"

I know we have the input files listed below now, but maybe it makes
sense to generate a "transcript" of all the input files here as a
block of comments?

I added the comment block from Chris.



+
+.. _IOManagerDirectives:
+
  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.
+.. Generated from spec:/rtems/io/if/register-driver

-.. raw:: latex
+.. index:: rtems_io_register_driver()
+.. index:: register a device driver

-   \clearpage

In the original docs, there is a page break on each new directive
including the first one. I guess now since the boilerplate text
description of Directives has been dropped it would just be a blank
page with Directives on it. This may be a minor point of
inconsistency. I think it looks fine without the page break since
there is no additional text. Joel?
I can also add a boilerplate text and clear the page before the first 
directive.



+.. _InterfaceRtemsIoRegisterDriver:

-.. index:: register a device driver
-.. index:: rtems_io_register_driver
-
-.. _rtems_io_register_driver:
-
-IO_REGISTER_DRIVER - Register a device driver
--
-
-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
-);
-
-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
-
-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.
-
-This directive automatically invokes the ``IO_INITIALIZE`` directive if the
-driver address table has an initialization and open 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.
-
-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_io_register_driver()
+--
+
+Registers and ini

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

[Sebastian Huber]

In the generated documentation please have a look at the IO and Event 
Manager.


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

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

[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.
---
v2:

* Add comments to mention the specification items which produced a
  content block.

* Preserve original directive order.

* Re-order sections so that the description is between the calling
  sequence and the return values.

* Use .. rubric instead of nested definition lists to fix the vertical
  spacing.

* Add custom document index entries.

v3:

* Improve automatically generated warning comment on top of the files

* Fix list layout in HTML output

* Add directive section boilerplate

* Drop "DIRECTIVE" from subsection titles ("PARAMETERS",
  "RETURN VALUES")

Generated PDF:

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

Generated HTML:

https://ftp.rtems.org/pub/rtems/people/sebh/c-user/html/index.html
 c-user/io/directives.rst   | 735 ++---
 c-user/io/introduction.rst |  62 +++-
 2 files changed, 481 insertions(+), 316 deletions(-)

diff --git a/c-user/io/directives.rst b/c-user/io/directives.rst
index d3098cb..7316f5a 100644
--- a/c-user/io/directives.rst
+++ b/c-user/io/directives.rst
@@ -1,421 +1,550 @@
 .. 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)
 
+.. 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:
+..
+.. https://docs.rtems.org/branches/master/eng/req/howto.html
+
+.. _IOManagerDirectives:
+
 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.
+This section details the directives of the I/O Manager. A subsection is
+dedicated to each of this manager's directives and lists the calling sequence,
+parameters, description, return values, and notes of the directive.
+
+.. Generated from spec:/rtems/io/if/register-driver
 
 .. raw:: latex
 
-   \clearpage
+\clearpage
 
+.. index:: rtems_io_register_driver()
 .. index:: register a device driver
-.. index:: rtems_io_register_driver
-
-.. _rtems_io_register_driver:
-
-IO_REGISTER_DRIVER - Register a device driver
--
-
-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
-);
-
-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
-
-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.
-
-This directive automatically invokes the ``IO_INITIALIZE`` directive if the
-driver address table has an initialization and open 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.
-
-NOTES:
-The Device Driver Table size is specified in the Configuration Table
-condiguration. This needs to be set to maximum size the application
-requires.
+
+.. _InterfaceRtemsIoRegisterDriver:
+
+rtems_io_register_driver()
+--
+
+Registers and initializes the device with the specified device driver address
+table and device major number in the Device Driver Table.
+
+.. rubric:: CALLING SEQUENCE:
+
+.. code-block:: c
+
+rtems_status_code rtems_io_register_driver(

Re: [PATCH] rtems: Improve RTEMS_NO_RETURN attribute

[Joel Sherrill]

This looks OK. Push it.

On Tue, Oct 6, 2020 at 1:06 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> Provide RTEMS_NO_RETURN also in case RTEMS_DEBUG is defined to prevent
> errors
> like this:
>
> error: no return statement in function returning non-void
> [-Werror=return-type]
>
> Use C11 and C++11 standard means to declare a no-return function.
>
> Close #4122.
> ---
>  cpukit/include/rtems/score/basedefs.h | 8 +---
>  1 file changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/cpukit/include/rtems/score/basedefs.h
> b/cpukit/include/rtems/score/basedefs.h
> index c31b4ebef7..0244af1471 100644
> --- a/cpukit/include/rtems/score/basedefs.h
> +++ b/cpukit/include/rtems/score/basedefs.h
> @@ -94,9 +94,11 @@
>   *  can impact the code generated following calls to
>   *  rtems_fatal_error_occurred and _Terminate.
>   */
> -#if defined(RTEMS_SCHEDSIM)
> -  #define RTEMS_NO_RETURN
> -#elif defined(__GNUC__) && !defined(RTEMS_DEBUG)
> +#if __cplusplus >= 201103L
> +  #define RTEMS_NO_RETURN [[noreturn]]
> +#elif __STDC_VERSION__ >= 201112L
> +  #define RTEMS_NO_RETURN _Noreturn
> +#elif defined(__GNUC__)
>#define RTEMS_NO_RETURN __attribute__((__noreturn__))
>  #else
>#define RTEMS_NO_RETURN
> --
> 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: Re: I can not run rtems 5.1 smp correctly on bsp xilinx-zynqmp

[Joel Sherrill]

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: Old network stack and aarch64

[Joel Sherrill]

On Tue, Oct 6, 2020 at 2:30 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> Hello,
>
> building the old network stack for aarch64 fails with:
>
> cpukit/librpc/src/xdr/xdr_float.c:121:2: error: #error "xdr_float.c:
> unknown CPU"
>121 | #error "xdr_float.c: unknown CPU"
>
> Should we enable RTEMS_NETWORKING more selectively similar to RTEMS_SMP
> and RTEMS_MULTIPROCESSING?
>

Yes for sure. In the autoconf system, we just excluded a few CPUs.

But should we go farther in waf? I see two possibilities:

+ Force legacy stack off for the same CPUs as autoconf build plus
   all the BSPs that have new stack support.

+ Only enable it for the specific BSPs that have HAS_NETWORKING
   in their Makefile.am?  A quick grep shows 37 of 84 families would be
   white listed this way.

The first is very easy. The second is a bit more painful but puts us on
a path of identifying specifically what has to transition.

With a bit of discussion on the rules for being white listed to use the
legacy stack, I would lean to the second solution.

--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: [PATCH v5] cpukit/librcxx: Add a C++ thread interface with attributes

[Joel Sherrill]

One last pile on. It is minor but you said "scheduler modes" for
inherit/explicit.  I couldn't place what bothered me about that wording.
This morning it hit me that modes is a Classic API term. I think your
comments could talk about it in these terms and use the POSIX terms like
scheduling attributes, policy, etc.

PTHREAD_INHERIT_SCHEDSpecifies that the thread scheduling attributes shall
be inherited from the creating thread, and the scheduling attributes in
this *attr* argument shall be ignored.PTHREAD_EXPLICIT_SCHEDSpecifies that
the thread scheduling attributes shall be set to the corresponding values
from this attributes object.


On Tue, Oct 6, 2020 at 1:13 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> Hello Chris,
>
> thanks, looks good.
>
> I would have added the stuff to  similar to
> , but this is a matter of taste.
>
> ___
> 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: Re: I can not run rtems 5.1 smp correctly on bsp xilinx-zynqmp

[Kinsey Moore]

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 
mailto: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 
mailto: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] rtems: Improve RTEMS_NO_RETURN attribute

[Sebastian Huber]

On 06/10/2020 15:09, Joel Sherrill wrote:


This looks OK. Push it.

Please have a look at v2 of the patch. It is an API breaking change.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] rtems: Improve RTEMS_NO_RETURN attribute

[Joel Sherrill]

How does it break the API? It looks like a change of annotation. Shouldn't
be a big deal unless I am misunderstanding something.

On Tue, Oct 6, 2020, 9:28 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> On 06/10/2020 15:09, Joel Sherrill wrote:
>
> > This looks OK. Push it.
> Please have a look at v2 of the patch. It is an API breaking change.
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] rtems: Improve RTEMS_NO_RETURN attribute

[Sebastian Huber]

On 06/10/2020 16:37, Joel Sherrill wrote:

How does it break the API? It looks like a change of annotation. 
Shouldn't be a big deal unless I am misunderstanding something.


Please have a look at:

https://lists.rtems.org/pipermail/devel/2020-October/062577.html

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

Re: [PATCH v4] cpukit/librcxx: Add a C++ thread interface with attributes

[Gedare Bloom]

On Mon, Oct 5, 2020 at 4:02 PM Chris Johns  wrote:
>
> On 5/10/20 6:36 pm, Sebastian Huber wrote:
> > On 03/10/2020 08:23, chr...@rtems.org wrote:
> >
> >> diff --git a/cpukit/include/rtems/c++/error 
> >> b/cpukit/include/rtems/c++/error
> >> new file mode 100644
> >> index 00..8b9d875e0f
> >> --- /dev/null
> >> +++ b/cpukit/include/rtems/c++/error
> >> @@ -0,0 +1,65 @@
> >> +/* -*- C++ -*-
> >> + * 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:
> >
> > Could you please use the new file template:
> >
> > https://docs.rtems.org/branches/master/eng/coding-file-hdr.html#c-c-header-file-template
> >
>
> Sure.
>
> > Do we really need editor-specific comments in the header files?
>
> Does it matter?
>

That depends. Is the filetype comment embedding standardized across
common editors?

> > Maybe just use a *.h or *.hpp header file name?
>
> The file namea are inline with the names C++ uses.
>

This is related. For example, Windows does not do well with
extensionless filenames. Neither do humans. It makes us have to guess
unless we open with our tools. I get that the C++ committee likes the
#include  without the .h/.hpp/.* but I find it annoying. I
also won't find these files with
find . -name "*.h*"
or any kind of regex for that matter. I'm not convinced about these
extensionless filenames at all.

> 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 v3] c-user: Generate I/O Manager documentation

[Gedare Bloom]

I just have one minor complaint now. In the HTML, I don't like that
"RETURN VALUES:"
appears to be about the same size/level/style as each of the list
elements below it. If you can make them more distinctive that would be
great. The PDF list isn't as bad because of the whitespace for the
list grouping.

On Tue, Oct 6, 2020 at 2:34 AM Sebastian Huber
 wrote:
>
> In the generated documentation please have a look at the IO and Event
> Manager.
>
> ___
> 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] rtems: Improve RTEMS_NO_RETURN attribute

[Joel Sherrill]

On Tue, Oct 6, 2020 at 9:46 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> On 06/10/2020 16:37, Joel Sherrill wrote:
>
> > How does it break the API? It looks like a change of annotation.
> > Shouldn't be a big deal unless I am misunderstanding something.
>
> Please have a look at:
>
> https://lists.rtems.org/pipermail/devel/2020-October/062577.html


Looks like basically the same code. What does this break? Why the concern?

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

Re: [PATCH] rtems: Improve RTEMS_NO_RETURN attribute

[Sebastian Huber]

On 06/10/2020 17:34, Joel Sherrill wrote:



On Tue, Oct 6, 2020 at 9:46 AM Sebastian Huber 
> wrote:


On 06/10/2020 16:37, Joel Sherrill wrote:

> How does it break the API? It looks like a change of annotation.
> Shouldn't be a big deal unless I am misunderstanding something.

Please have a look at:

https://lists.rtems.org/pipermail/devel/2020-October/062577.html


Looks like basically the same code. What does this break? Why the concern?


The C11/C++11 attribute syntax is less flexible compared to the GNU 
attributes. For example:


echo "_Noreturn void ok(void);" > test.c

echo "void error(void) _Noreturn;" >> test.c

gcc test.c

test.c: In function ‘error’:
test.c:2:1: error: ‘_Noreturn’ in empty declaration
 void error(void) _Noreturn;
 ^~~~
test.c:2:18: warning: empty declaration
 void error(void) _Noreturn;
  ^
test.c:2:1: error: expected ‘{’ at end of input
 void error(void) _Noreturn;
 ^~~~

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

Re: [PATCH] rtems: Improve RTEMS_NO_RETURN attribute

[Joel Sherrill]

On Tue, Oct 6, 2020 at 10:41 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> On 06/10/2020 17:34, Joel Sherrill wrote:
>
> >
> > On Tue, Oct 6, 2020 at 9:46 AM Sebastian Huber
> >  > > wrote:
> >
> > On 06/10/2020 16:37, Joel Sherrill wrote:
> >
> > > How does it break the API? It looks like a change of annotation.
> > > Shouldn't be a big deal unless I am misunderstanding something.
> >
> > Please have a look at:
> >
> > https://lists.rtems.org/pipermail/devel/2020-October/062577.html
> >
> >
> > Looks like basically the same code. What does this break? Why the
> concern?
>
> The C11/C++11 attribute syntax is less flexible compared to the GNU
> attributes. For example:
>
> echo "_Noreturn void ok(void);" > test.c
>
> echo "void error(void) _Noreturn;" >> test.c
>
> gcc test.c
>
> test.c: In function ‘error’:
> test.c:2:1: error: ‘_Noreturn’ in empty declaration
>   void error(void) _Noreturn;
>   ^~~~
> test.c:2:18: warning: empty declaration
>   void error(void) _Noreturn;
>^
> test.c:2:1: error: expected ‘{’ at end of input
>   void error(void) _Noreturn;
>   ^~~~
>
>
Yuck. I can see why they did the placement kind of. Makes it like const
or static but it uses an odd keyword with leading _ and capital letter
which is rather insane.

What's the positive value for doing this? Does llvm or some static
analyser like it better?

C11 has improvements but it also has more than one thing I
question if they really thought through. :(

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

Re: [PATCH] rtems: Improve RTEMS_NO_RETURN attribute

[Sebastian Huber]

On 06/10/2020 17:55, Joel Sherrill wrote:




On Tue, Oct 6, 2020 at 10:41 AM Sebastian Huber 
> wrote:


On 06/10/2020 17:34, Joel Sherrill wrote:

>
> On Tue, Oct 6, 2020 at 9:46 AM Sebastian Huber
> mailto:sebastian.hu...@embedded-brains.de>
> >> wrote:
>
>     On 06/10/2020 16:37, Joel Sherrill wrote:
>
>     > How does it break the API? It looks like a change of
annotation.
>     > Shouldn't be a big deal unless I am misunderstanding
something.
>
>     Please have a look at:
>
> https://lists.rtems.org/pipermail/devel/2020-October/062577.html
>
>
> Looks like basically the same code. What does this break? Why
the concern?

The C11/C++11 attribute syntax is less flexible compared to the GNU
attributes. For example:

echo "_Noreturn void ok(void);" > test.c

echo "void error(void) _Noreturn;" >> test.c

gcc test.c

test.c: In function ‘error’:
test.c:2:1: error: ‘_Noreturn’ in empty declaration
  void error(void) _Noreturn;
  ^~~~
test.c:2:18: warning: empty declaration
  void error(void) _Noreturn;
   ^
test.c:2:1: error: expected ‘{’ at end of input
  void error(void) _Noreturn;
  ^~~~


Yuck. I can see why they did the placement kind of. Makes it like const
or static but it uses an odd keyword with leading _ and capital letter
which is rather insane.
All new keywords in C are like this. You can include  to 
get something without the underscore.


What's the positive value for doing this? Does llvm or some static
analyser like it better?

The positive thing is being in line with the standard.


C11 has improvements but it also has more than one thing I
question if they really thought through. :(


Yes, I guess not every C compiler vendor liked the GNU attribute stuff. 
C++11 has a similar issue:


[[noreturn]] void ok(void);
void error(void) [[noreturn]];

g++ test.cc
test.cc:2:29: warning: attribute ignored [-Wattributes]
 void error(void) [[noreturn]];
 ^
test.cc:2:29: note: an attribute that appertains to a type-specifier is 
ignored


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

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

[Sebastian Huber]

On 06/10/2020 17:06, Gedare Bloom wrote:


I just have one minor complaint now. In the HTML, I don't like that
"RETURN VALUES:"
appears to be about the same size/level/style as each of the list
elements below it. If you can make them more distinctive that would be
great. The PDF list isn't as bad because of the whitespace for the
list grouping.


I think this can be done via the CSS:

build/c-user/html/partition/directives.html:RETURN 
VALUES:


I don't know off hand how this works.

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

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

[Sebastian Huber]

On 06/10/2020 19:04, Sebastian Huber wrote:


On 06/10/2020 17:06, Gedare Bloom wrote:


I just have one minor complaint now. In the HTML, I don't like that
"RETURN VALUES:"
appears to be about the same size/level/style as each of the list
elements below it. If you can make them more distinctive that would be
great. The PDF list isn't as bad because of the whitespace for the
list grouping.


I think this can be done via the CSS:

build/c-user/html/partition/directives.html:RETURN 
VALUES:


I don't know off hand how this works. 
Another approach is to format the values as ``value``. This changes the 
font in the output. Additionally, in the HTML output the font colour is 
greenish.

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

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

[Sebastian Huber]

On 06/10/2020 19:33, Sebastian Huber wrote:


On 06/10/2020 19:04, Sebastian Huber wrote:


On 06/10/2020 17:06, Gedare Bloom wrote:


I just have one minor complaint now. In the HTML, I don't like that
"RETURN VALUES:"
appears to be about the same size/level/style as each of the list
elements below it. If you can make them more distinctive that would be
great. The PDF list isn't as bad because of the whitespace for the
list grouping.


I think this can be done via the CSS:

build/c-user/html/partition/directives.html:RETURN 
VALUES:


I don't know off hand how this works. 
Another approach is to format the values as ``value``. This changes 
the font in the output. Additionally, in the HTML output the font 
colour is greenish. 


It looks good from my point of view. The formatting is now consistent 
with the formatting in the text.


Generated PDF:

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

Generated HTML:

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

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

BSP Count (rtems-bsps, autoconf, and waf)

[Joel Sherrill]

Hi

./rtems-bsps looks for *.cfg and reports the following:

Architectures: 17
BSP Families: 84
BSPs: 189

I know it overcounts by one since it sees bbxm.cfg as a BSP configuration
while when it is for a simulator.

But "find . -name "bsp*.yml" | wc -l" only reports 184.

(1) rtems-bsps will eventually need to be converted to find BSPs based on
waf

(2) Why the discrepancy? What's the right way to find the set of BSPs?

My BSP sweep is using the set reported by rtems-bsps minus bbxm as the set
to build so they all must be building.

Thanks.

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

Ticket keyword "wafblocker"

[Joel Sherrill]

Hi

As the testing looks better and better, I am beginning to think of other
things that have to be touched for the waf switchover. I am filing tickets
as I think of them.  These are mostly small things that I would prefer to
catch now. I don't want this to take as long as it did to purge all the sis
references when that BSP variant disappeared.

Without any better ideas, I am using the keyword "wafblocker".

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

Re: Failures from Partial BSP Build Sweep

[Joel Sherrill]

About 1/2 of the way through and up to the PowerPC.
I know Sebastian committed some fixes so a few of these
may already be fixed. The failures reported are all ARM so far:

FAILED (2)  autoconf build of arm lm3s3749 (NOSMP/NOMP/DEBUG/PROFILE)
FAILED (1)  waf build of arm lm3s3749 (NOSMP/NOMP/DEBUG/PROFILE)
FAILED (2)  autoconf build of arm lm3s3749 (NOSMP/NOMP/DEBUG/NOPROFILE)
FAILED (2)  autoconf build of arm lpc2362 (NOSMP/NOMP/DEBUG/PROFILE)
FAILED (1)  waf build of arm lpc2362 (NOSMP/NOMP/DEBUG/PROFILE)
FAILED (2)  autoconf build of arm lpc2362 (NOSMP/NOMP/DEBUG/NOPROFILE)
FAILED (1)  waf build of arm lpc2362 (NOSMP/NOMP/DEBUG/NOPROFILE)
FAILED (1)  waf build of arm lpc23xx_tli800 (NOSMP/NOMP/DEBUG/PROFILE)
FAILED (1)  waf build of arm lpc23xx_tli800 (NOSMP/NOMP/DEBUG/NOPROFILE)
FAILED (2)  autoconf build of arm lpc32xx_mzx_stage_1
(NOSMP/NOMP/DEBUG/PROFILE)
FAILED (2)  autoconf build of arm lpc32xx_mzx_stage_1
(NOSMP/NOMP/DEBUG/NOPROFILE)
FAILED (2)  autoconf build of arm raspberrypi (SMP/NOMP/DEBUG/PROFILE)
FAILED (1)  waf build of arm raspberrypi (SMP/NOMP/DEBUG/PROFILE)
FAILED (2)  autoconf build of arm raspberrypi (SMP/NOMP/DEBUG/NOPROFILE)
FAILED (1)  waf build of arm raspberrypi (SMP/NOMP/DEBUG/NOPROFILE)
FAILED (2)  autoconf build of arm raspberrypi (SMP/NOMP/NODEBUG/PROFILE)
FAILED (1)  waf build of arm raspberrypi (SMP/NOMP/NODEBUG/PROFILE)
FAILED (2)  autoconf build of arm raspberrypi (SMP/NOMP/NODEBUG/NOPROFILE)
FAILED (1)  waf build of arm raspberrypi (SMP/NOMP/NODEBUG/NOPROFILE)

Thanks.

--joel

On Mon, Oct 5, 2020 at 6:57 PM Joel Sherrill  wrote:

> Hi
>
> Sebastian's fix for testopts seems to have resolved a lot of build
> failures. My build is ~220 BSPs in and this is the current set of failure
> messages:
>
> FAILED (2)  autoconf build of arm lm3s3749 (NOSMP/NOMP/DEBUG/PROFILE)
> FAILED (1)  waf build of arm lm3s3749 (NOSMP/NOMP/DEBUG/PROFILE)
> FAILED (2)  autoconf build of arm lm3s3749 (NOSMP/NOMP/DEBUG/NOPROFILE)
> FAILED (2)  autoconf build of arm lpc2362 (NOSMP/NOMP/DEBUG/PROFILE)
> FAILED (1)  waf build of arm lpc2362 (NOSMP/NOMP/DEBUG/PROFILE)
> FAILED (2)  autoconf build of arm lpc2362 (NOSMP/NOMP/DEBUG/NOPROFILE)
> FAILED (1)  waf build of arm lpc2362 (NOSMP/NOMP/DEBUG/NOPROFILE)
> FAILED (1)  waf build of arm lpc23xx_tli800 (NOSMP/NOMP/DEBUG/PROFILE)
> FAILED (1)  waf build of arm lpc23xx_tli800 (NOSMP/NOMP/DEBUG/NOPROFILE)
>
> Given the timezones, I hope some of those can disappear before I get on in
> the morning. :)
>
> Full report when the sweep is finished.
>
> --joel
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH v5] cpukit/librcxx: Add a C++ thread interface with attributes

[Chris Johns]

On 6/10/20 5:12 pm, Sebastian Huber wrote:
> thanks, looks good.

Great :)

> I would have added the stuff to  similar to
> 

That is a great idea. I did not like `c++` in the path but I also did not think
`rtems/thread` was suitable.

> but this is a matter of taste.

I do not like .hpp as an extension but in this case with a mixed C and now C++
set of interfaces it makes sense.

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

Re: [PATCH v5] cpukit/librcxx: Add a C++ thread interface with attributes

[Chris Johns]

On 7/10/20 12:33 am, Joel Sherrill wrote:
> One last pile on. 

No problem and thanks. The reviews are great.

> It is minor but you said "scheduler modes" for
> inherit/explicit.  I couldn't place what bothered me about that wording. This
> morning it hit me that modes is a Classic API term. I think your comments 
> could
> talk about it in these terms and use the POSIX terms like scheduling 
> attributes,
> policy, etc.
> 
> PTHREAD_INHERIT_SCHED
> Specifies that the thread scheduling attributes shall be inherited from 
> the
> creating thread, and the scheduling attributes in this /attr/ argument 
> shall
> be ignored.
> PTHREAD_EXPLICIT_SCHED
> Specifies that the thread scheduling attributes shall be set to the
> corresponding values from this attributes object.

How about this ...

  /**
   * The scheduler attributes.
   */
  enum sched_attr {
sched_inherit,/**< Inherit the scheduler attributes
   *   from the creating thread. */
sched_explicit/**< Explicitly set the scheduler to these
   *   attributes. */
  };

  /**
   * Get the attributes' scheduler attribute for the thread.
   *
   * @return sched_attr The attributes' scheduler attribute
   */
  sched_attr get_scheduler_attr () const;

etc?

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

Re: [PATCH v5] cpukit/librcxx: Add a C++ thread interface with attributes

[Joel Sherrill]

On Tue, Oct 6, 2020 at 4:58 PM Chris Johns  wrote:

> On 7/10/20 12:33 am, Joel Sherrill wrote:
> > One last pile on.
>
> No problem and thanks. The reviews are great.
>
> > It is minor but you said "scheduler modes" for
> > inherit/explicit.  I couldn't place what bothered me about that wording.
> This
> > morning it hit me that modes is a Classic API term. I think your
> comments could
> > talk about it in these terms and use the POSIX terms like scheduling
> attributes,
> > policy, etc.
> >
> > PTHREAD_INHERIT_SCHED
> > Specifies that the thread scheduling attributes shall be inherited
> from the
> > creating thread, and the scheduling attributes in
> this /attr/ argument shall
> > be ignored.
> > PTHREAD_EXPLICIT_SCHED
> > Specifies that the thread scheduling attributes shall be set to the
> > corresponding values from this attributes object.
>
> How about this ...
>
>   /**
>* The scheduler attributes.
>*/
>   enum sched_attr {
> sched_inherit,/**< Inherit the scheduler attributes
>*   from the creating thread. */
> sched_explicit/**< Explicitly set the scheduler to these
>*   attributes. */
>   };
>
>   /**
>* Get the attributes' scheduler attribute for the thread.
>*
>* @return sched_attr The attributes' scheduler attribute
>*/
>   sched_attr get_scheduler_attr () const;
>
> etc?
>

That's good. It's easy to mix terminology from the various APIs.

--joel

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

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

[Chris Johns]

On 7/10/20 4:04 am, Sebastian Huber wrote:
> On 06/10/2020 17:06, Gedare Bloom wrote:
> 
>> I just have one minor complaint now. In the HTML, I don't like that
>> "RETURN VALUES:"
>> appears to be about the same size/level/style as each of the list
>> elements below it. If you can make them more distinctive that would be
>> great. The PDF list isn't as bad because of the whitespace for the
>> list grouping.
> 
> I think this can be done via the CSS:
> 
> build/c-user/html/partition/directives.html:RETURN 
> VALUES:
> 
> I don't know off hand how this works.

I can sort this out once the change is pushed.

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

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

[Chris Johns]

On 7/10/20 4:40 am, Sebastian Huber wrote:
> On 06/10/2020 19:33, Sebastian Huber wrote:
> 
>> On 06/10/2020 19:04, Sebastian Huber wrote:
>>
>>> On 06/10/2020 17:06, Gedare Bloom wrote:
>>>
 I just have one minor complaint now. In the HTML, I don't like that
 "RETURN VALUES:"
 appears to be about the same size/level/style as each of the list
 elements below it. If you can make them more distinctive that would be
 great. The PDF list isn't as bad because of the whitespace for the
 list grouping.
>>>
>>> I think this can be done via the CSS:
>>>
>>> build/c-user/html/partition/directives.html:RETURN 
>>> VALUES:
>>>
>>> I don't know off hand how this works. 
>> Another approach is to format the values as ``value``. This changes the font
>> in the output. Additionally, in the HTML output the font colour is greenish. 
> 
> It looks good from my point of view. The formatting is now consistent with the
> formatting in the text.
> 
> Generated PDF:
> 
> https://ftp.rtems.org/pub/rtems/people/sebh/c-user-7.pdf
> 
> Generated HTML:
> 
> https://ftp.rtems.org/pub/rtems/people/sebh/c-user/html/index.html
> 

Looks good.

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

Re: [PATCH v4] cpukit/librcxx: Add a C++ thread interface with attributes

[Chris Johns]

On 7/10/20 1:55 am, Gedare Bloom wrote:
> On Mon, Oct 5, 2020 at 4:02 PM Chris Johns  wrote:
>>
>> On 5/10/20 6:36 pm, Sebastian Huber wrote:
>>> On 03/10/2020 08:23, chr...@rtems.org wrote:
>>>
 diff --git a/cpukit/include/rtems/c++/error 
 b/cpukit/include/rtems/c++/error
 new file mode 100644
 index 00..8b9d875e0f
 --- /dev/null
 +++ b/cpukit/include/rtems/c++/error
 @@ -0,0 +1,65 @@
 +/* -*- C++ -*-
 + * 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:
>>>
>>> Could you please use the new file template:
>>>
>>> https://docs.rtems.org/branches/master/eng/coding-file-hdr.html#c-c-header-file-template
>>>
>>
>> Sure.
>>
>>> Do we really need editor-specific comments in the header files?
>>
>> Does it matter?
>>
> 
> That depends. Is the filetype comment embedding standardized across
> common editors?

I do not know but the names will change. :)

I feel we should be OK with editor comments if they are needed. In this case we
can avoid them for other reasons.

>>> Maybe just use a *.h or *.hpp header file name?
>>
>> The file namea are inline with the names C++ uses.
>>
> 
> This is related. For example, Windows does not do well with
> extensionless filenames.

MSVC supports the standard's naming.

> Neither do humans. It makes us have to guess
> unless we open with our tools. I get that the C++ committee likes the
> #include  without the .h/.hpp/.* but I find it annoying. I
> also won't find these files with
> find . -name "*.h*"
> or any kind of regex for that matter. I'm not convinced about these
> extensionless filenames at all.

I do not know the history to suitably debate the merits. The C++ standards
people made this change for C++ as the early versions of C++ such as cfront 3.0
used .h. They may document the reason.

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

[PATCH v6] cpukit/librcxx: Add a C++ thread interface with attributes

[chrisj]

From: Chris Johns 

---
 cpukit/include/rtems/error.hpp|  68 +++
 cpukit/include/rtems/thread.hpp   | 477 ++
 cpukit/librtemscxx/error.cpp  |  76 
 cpukit/librtemscxx/thread.cpp | 416 +++
 spec/build/cpukit/grp.yml |   2 +
 spec/build/cpukit/librtemscxx.yml |  21 +
 spec/build/testsuites/libtests/grp.yml|   2 +
 spec/build/testsuites/libtests/rcxx01.yml |  22 +
 testsuites/libtests/rcxx01/init.c |  89 
 testsuites/libtests/rcxx01/rcxx01.doc |  16 +
 testsuites/libtests/rcxx01/rcxx01.scn |  13 +
 testsuites/libtests/rcxx01/thread.cpp | 110 +
 12 files changed, 1312 insertions(+)
 create mode 100644 cpukit/include/rtems/error.hpp
 create mode 100644 cpukit/include/rtems/thread.hpp
 create mode 100644 cpukit/librtemscxx/error.cpp
 create mode 100644 cpukit/librtemscxx/thread.cpp
 create mode 100644 spec/build/cpukit/librtemscxx.yml
 create mode 100644 spec/build/testsuites/libtests/rcxx01.yml
 create mode 100644 testsuites/libtests/rcxx01/init.c
 create mode 100644 testsuites/libtests/rcxx01/rcxx01.doc
 create mode 100644 testsuites/libtests/rcxx01/rcxx01.scn
 create mode 100644 testsuites/libtests/rcxx01/thread.cpp

diff --git a/cpukit/include/rtems/error.hpp b/cpukit/include/rtems/error.hpp
new file mode 100644
index 00..a62ee966c6
--- /dev/null
+++ b/cpukit/include/rtems/error.hpp
@@ -0,0 +1,68 @@
+/* SPDX-License-Identifier: BSD-2-Clause */
+
+/**
+ * @file
+ *
+ * @ingroup RTEMSC++
+ *
+ * @brief RTEMS Error exception.
+ *
+ * Provide an error exception for RTEMS errors.
+ */
+
+/*
+ * 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.
+ */
+
+#if !defined(RTEMS_ERROR_HPP)
+#define RTEMS_ERROR_HPP
+
+#include 
+#include 
+
+#include 
+
+namespace rtems
+{
+  class runtime_error :
+public std::runtime_error
+  {
+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 ();
+  };
+
+  /**
+   * 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);
+};
+
+#endif
diff --git a/cpukit/include/rtems/thread.hpp b/cpukit/include/rtems/thread.hpp
new file mode 100644
index 00..e90e664dfa
--- /dev/null
+++ b/cpukit/include/rtems/thread.hpp
@@ -0,0 +1,477 @@
+/* SPDX-License-Identifier: BSD-2-Clause */
+
+/**
+ * @file
+ *
+ * @ingroup RTEMSC++
+ *
+ * @brief C++ standard thread support with thread attribute control.
+ *
+ * Provide a way to create a thread in C++ with attributes that let
+ * you control the real-time embedded parameters need to run
+ * threads on RTEMS.
+ *
+ * The code requires the `-std=c++17` option to access `std::invoke()`.
+ */
+
+/*
+ * 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 mat

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

[Gedare Bloom]

On Tue, Oct 6, 2020 at 4:08 PM Chris Johns  wrote:
>
> On 7/10/20 4:40 am, Sebastian Huber wrote:
> > On 06/10/2020 19:33, Sebastian Huber wrote:
> >
> >> On 06/10/2020 19:04, Sebastian Huber wrote:
> >>
> >>> On 06/10/2020 17:06, Gedare Bloom wrote:
> >>>
>  I just have one minor complaint now. In the HTML, I don't like that
>  "RETURN VALUES:"
>  appears to be about the same size/level/style as each of the list
>  elements below it. If you can make them more distinctive that would be
>  great. The PDF list isn't as bad because of the whitespace for the
>  list grouping.
> >>>
> >>> I think this can be done via the CSS:
> >>>
> >>> build/c-user/html/partition/directives.html:RETURN 
> >>> VALUES:
> >>>
> >>> I don't know off hand how this works.
> >> Another approach is to format the values as ``value``. This changes the 
> >> font
> >> in the output. Additionally, in the HTML output the font colour is 
> >> greenish.
> >
> > It looks good from my point of view. The formatting is now consistent with 
> > the
> > formatting in the text.
> >
> > Generated PDF:
> >
> > https://ftp.rtems.org/pub/rtems/people/sebh/c-user-7.pdf
> >
> > Generated HTML:
> >
> > https://ftp.rtems.org/pub/rtems/people/sebh/c-user/html/index.html
> >
>
> Looks good.
>
I agree.

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

Re: Old network stack and aarch64

[Chris Johns]

On 7/10/20 12:26 am, Joel Sherrill wrote:
> On Tue, Oct 6, 2020 at 2:30 AM Sebastian Huber
>  >
> wrote:
> 
> Hello,
> 
> building the old network stack for aarch64 fails with:
> 
> cpukit/librpc/src/xdr/xdr_float.c:121:2: error: #error "xdr_float.c:
> unknown CPU"
>    121 | #error "xdr_float.c: unknown CPU"
> 
> Should we enable RTEMS_NETWORKING more selectively similar to RTEMS_SMP
> and RTEMS_MULTIPROCESSING?
> 
> 
> Yes for sure. In the autoconf system, we just excluded a few CPUs.

Yes

> But should we go farther in waf? I see two possibilities:
> 
> + Force legacy stack off for the same CPUs as autoconf build plus
>    all the BSPs that have new stack support.
> 
> + Only enable it for the specific BSPs that have HAS_NETWORKING
>    in their Makefile.am?  A quick grep shows 37 of 84 families would be
>    white listed this way. 

+ The --enable-networking and waf equivalent should indicate the option is
depreciated.

> The first is very easy. The second is a bit more painful but puts us on
> a path of identifying specifically what has to transition.
> 
> With a bit of discussion on the rules for being white listed to use the
> legacy stack, I would lean to the second solution.

What about users with private drivers in their code base? I know of zynq users
with such drivers.

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

Legacy networking stack removal

[Chris Johns]

Hi,

What is the life span of the legacy stack in rtems.git? I see this software as a
liability.

I think it is hard to actively encourage our users to use libbsd if we have an
enable or waf equivalent at hand in rtems.git.

I know of one serious issue in the stack related to the ARP cache and Windows.

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

Re: Legacy networking stack removal

[Joel Sherrill]

On Tue, Oct 6, 2020, 6:16 PM Chris Johns  wrote:

> Hi,
>
> What is the life span of the legacy stack in rtems.git? I see this
> software as a
> liability.
>

I'd love it to be a sliver over autoconf.

>
> I think it is hard to actively encourage our users to use libbsd if we
> have an
> enable or waf equivalent at hand in rtems.git.
>

I'd love it to go in its own separate repo. Is that at all possible? What's
required?

>
> I know of one serious issue in the stack related to the ARP cache and
> Windows.
>
> Thanks
> 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: Legacy networking stack removal

[Chris Johns]

On 7/10/20 10:21 am, Joel Sherrill wrote:
> On Tue, Oct 6, 2020, 6:16 PM Chris Johns  > wrote:
> 
> What is the life span of the legacy stack in rtems.git? I see this 
> software as a
> liability.
> 
> I'd love it to be a sliver over autoconf.

Sounds like a plan. I have created a task against the 6.1 milestone:

https://devel.rtems.org/ticket/4126

> I think it is hard to actively encourage our users to use libbsd if we 
> have an
> enable or waf equivalent at hand in rtems.git.
> 
> I'd love it to go in its own separate repo. Is that at all possible? What's
> required? 

I suggest we move it to a top level repo with the network demo code and then see
what happens. In theory it should be easy to build with rtems_waf.

The remaining fragments of code can be removed from the BSP files and maybe
moved to a header file in the new repo once we have made the split.

The change will break existing users but I think we need to make the change.
Users who still depend on this stack need to either post here and make us aware,
post fixes or directly contact you, me or others for support options.

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

Re: [PATCH v6] cpukit/librcxx: Add a C++ thread interface with attributes

[Sebastian Huber]

Looks good.

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

Re: Legacy networking stack removal

[Sebastian Huber]

On 07/10/2020 02:07, Chris Johns wrote:


On 7/10/20 10:21 am, Joel Sherrill wrote:

On Tue, Oct 6, 2020, 6:16 PM Chris Johns mailto:chr...@rtems.org>> wrote:

 What is the life span of the legacy stack in rtems.git? I see this 
software as a
 liability.

I'd love it to be a sliver over autoconf.

Sounds like a plan. I have created a task against the 6.1 milestone:

https://devel.rtems.org/ticket/4126


 I think it is hard to actively encourage our users to use libbsd if we 
have an
 enable or waf equivalent at hand in rtems.git.

I'd love it to go in its own separate repo. Is that at all possible? What's
required?

I suggest we move it to a top level repo with the network demo code and then see
what happens. In theory it should be easy to build with rtems_waf.

The remaining fragments of code can be removed from the BSP files and maybe
moved to a header file in the new repo once we have made the split.

The change will break existing users but I think we need to make the change.
Users who still depend on this stack need to either post here and make us aware,
post fixes or directly contact you, me or others for support options.
Maintaining or removing the old network stack is both fine for me. 
Moving the stuff out of the RTEMS repository is a bit of work.

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

[PATCH] build: Disable RTEMS_NETWORKING for some arch/bsp

[Sebastian Huber]

The old network stack is not supported on 64-bit targets.
---
 spec/build/cpukit/optnet.yml | 12 +++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/spec/build/cpukit/optnet.yml b/spec/build/cpukit/optnet.yml
index 8678c8dbb8..7b0acf9083 100644
--- a/spec/build/cpukit/optnet.yml
+++ b/spec/build/cpukit/optnet.yml
@@ -10,7 +10,17 @@ default: false
 default-by-variant: []
 description: |
   Enable the legacy TCP/IP network support
-enabled-by: true
+enabled-by:
+  not:
+- aarch64
+- powerpc/qoriq_e6500_64
+- riscv/rv64imac
+- riscv/rv64imac_medany
+- riscv/rv64imafd
+- riscv/rv64imafd_medany
+- riscv/rv64imafdc
+- riscv/rv64imafdc_medany
+- x86_64
 links: []
 name: RTEMS_NETWORKING
 type: build
-- 
2.26.2

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

Re: BSP Count (rtems-bsps, autoconf, and waf)

[Sebastian Huber]

Here is the difference:

--- old 2020-10-07 08:01:12.249050086 +0200
+++ new 2020-10-07 08:00:51.436897826 +0200
@@ -1,6 +1,7 @@
+aarch64/a53_ilp32_qemu
+aarch64/a53_lp64_qemu
 arm/altcycv_devkit
 arm/atsamv
-arm/bbxm
 arm/beagleboardorig
 arm/beagleboardxm
 arm/beagleboneblack
@@ -95,7 +96,6 @@
 mips/rbtx4938
 moxie/moxiesim
 nios2/nios2_iss
-no_cpu/no_bsp
 or1k/generic_or1k
 powerpc/beatnik
 powerpc/br_uid
@@ -143,25 +142,17 @@
 riscv/grv32imac
 riscv/grv32imafdc
 riscv/rv32i
-riscv/rv32i_clang
 riscv/rv32iac
-riscv/rv32iac_clang
 riscv/rv32im
-riscv/rv32im_clang
 riscv/rv32imac
-riscv/rv32imac_clang
 riscv/rv32imafc
-riscv/rv32imafc_clang
 riscv/rv32imafd
-riscv/rv32imafd_clang
 riscv/rv32imafdc
-riscv/rv32imafdc_clang
 riscv/rv64imac
 riscv/rv64imac_medany
 riscv/rv64imafd
 riscv/rv64imafd_medany
 riscv/rv64imafdc
-riscv/rv64imafdc_clang
 riscv/rv64imafdc_medany
 sh/gensh1
 sh/gensh2

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