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

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

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

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

Re: Legacy networking stack removal

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 au

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

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

Re: Legacy networking stack removal

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

Re: Legacy networking stack removal

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

Legacy networking stack removal

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 Wind

Re: Old network stack and aarch64

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_fl

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

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

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

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

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

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 mo

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

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

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

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 di

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

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

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

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 thi

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

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 exte

Re: Failures from Partial BSP Build Sweep

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/

Ticket keyword "wafblocker"

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 s

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

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 eventu

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

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 bel

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

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 t

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

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

Re: [PATCH] rtems: Improve RTEMS_NO_RETURN attribute

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

Re: [PATCH] rtems: Improve RTEMS_NO_RETURN attribute

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 Sherril

Re: [PATCH] rtems: Improve RTEMS_NO_RETURN attribute

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 unl

Re: [PATCH] rtems: Improve RTEMS_NO_RETURN attribute

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

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

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 group

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

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

Re: [PATCH] rtems: Improve RTEMS_NO_RETURN attribute

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 _

Re: [PATCH] rtems: Improve RTEMS_NO_RETURN attribute

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

Re: [PATCH] rtems: Improve RTEMS_NO_RETURN attribute

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: Re: I can not run rtems 5.1 smp correctly on bsp xilinx-zynqmp

Is it possible that the application was only started on the first core instead of all cores? Is it possible to check the execution state of the other cores? Kinsey From: Joel Sherrill Sent: Tuesday, October 6, 2020 08:11 To: small...@aliyun.com Cc: Gedare Bloom ; devel ; Kinsey Moore Subject:

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

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 attribu

Re: Old network stack and aarch64

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

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

Maybe Kinsey has an idea. On Tue, Oct 6, 2020 at 1:29 AM small...@aliyun.com wrote: > The board is Ultra96 board with JTAG boot. > And yes, there is a bspsmp.c in rtems-5.1\bsps\arm\xilinx-zynqmp\start\ > > -- > small...@aliyun.com > > > *From:* Gedare Bloom > *Date:

Re: [PATCH] rtems: Improve RTEMS_NO_RETURN attribute

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]

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

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 me

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

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

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

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

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

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 e

[PATCH v2] rtems: Improve RTEMS_NO_RETURN attribute

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

Re: [PATCH] rtems: Improve RTEMS_NO_RETURN attribute

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

Old network stack and aarch64

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