[PATCH] c-user: Reformat configuration option constraints

[Sebastian Huber]

If only one constraint is present, then use a single sentence, otherwise
use a list for the constraints.  Format the constraints so that the line
length limit is maintained.
---
 c-user/config/bdbuf.rst |  94 ++-
 c-user/config/bsp-related.rst   |  22 ++--
 c-user/config/classic-api.rst   | 176 ++--
 c-user/config/classic-init-task.rst |  28 +++--
 c-user/config/device-driver.rst |  18 +--
 c-user/config/event-record.rst  |  11 +-
 c-user/config/filesystem.rst|   6 +-
 c-user/config/general.rst   | 114 ++
 c-user/config/idle-task.rst |  12 +-
 c-user/config/mpci.rst  |  50 +---
 c-user/config/posix-api.rst | 168 +-
 c-user/config/posix-init-thread.rst |  11 +-
 c-user/config/scheduler-general.rst |  28 ++---
 c-user/config/task-stack-alloc.rst  |   6 +-
 14 files changed, 414 insertions(+), 330 deletions(-)

diff --git a/c-user/config/bdbuf.rst b/c-user/config/bdbuf.rst
index 7377bee..c5381e1 100644
--- a/c-user/config/bdbuf.rst
+++ b/c-user/config/bdbuf.rst
@@ -1,6 +1,6 @@
 .. SPDX-License-Identifier: CC-BY-SA-4.0
 
-.. Copyright (C) 2020 embedded brains GmbH (http://www.embedded-brains.de)
+.. Copyright (C) 2020, 2021 embedded brains GmbH 
(http://www.embedded-brains.de)
 .. Copyright (C) 1988, 2008 On-Line Applications Research Corporation (OAR)
 
 .. This file is part of the RTEMS quality process and was automatically
@@ -76,9 +76,10 @@ VALUE CONSTRAINTS:
 The value of this configuration option shall satisfy all of the following
 constraints:
 
-* It shall be greater than or equal to 0.
+* It shall be greater than or equal to zero.
 
-* It shall be an integral multiple of 
:ref:`CONFIGURE_BDBUF_BUFFER_MIN_SIZE`.
+* It shall be an integral multiple of
+  :ref:`CONFIGURE_BDBUF_BUFFER_MIN_SIZE`.
 
 DESCRIPTION:
 The value of this configuration option defines the maximum size of a buffer
@@ -106,8 +107,13 @@ DEFAULT VALUE:
 The default value is 512.
 
 VALUE CONSTRAINTS:
-The value of this configuration option shall be greater than or equal to 0
-and less than or equal to `UINT32_MAX 
`_.
+The value of this configuration option shall satisfy all of the following
+constraints:
+
+* It shall be greater than or equal to zero.
+
+* It shall be less than or equal to `UINT32_MAX
+  `_.
 
 DESCRIPTION:
 The value of this configuration option defines the minimum size of a buffer
@@ -135,8 +141,13 @@ DEFAULT VALUE:
 The default value is 32768.
 
 VALUE CONSTRAINTS:
-The value of this configuration option shall be greater than or equal to 0
-and less than or equal to `SIZE_MAX 
`_.
+The value of this configuration option shall satisfy all of the following
+constraints:
+
+* It shall be greater than or equal to zero.
+
+* It shall be less than or equal to `SIZE_MAX
+  `_.
 
 DESCRIPTION:
 The value of this configuration option defines the size of the cache memory
@@ -164,8 +175,13 @@ DEFAULT VALUE:
 The default value is 0.
 
 VALUE CONSTRAINTS:
-The value of this configuration option shall be greater than or equal to 0
-and less than or equal to `UINT32_MAX 
`_.
+The value of this configuration option shall satisfy all of the following
+constraints:
+
+* It shall be greater than or equal to zero.
+
+* It shall be less than or equal to `UINT32_MAX
+  `_.
 
 DESCRIPTION:
 The value of this configuration option defines the maximum blocks per
@@ -195,8 +211,13 @@ DEFAULT VALUE:
 The default value is 16.
 
 VALUE CONSTRAINTS:
-The value of this configuration option shall be greater than or equal to 0
-and less than or equal to `UINT32_MAX 
`_.
+The value of this configuration option shall satisfy all of the following
+constraints:
+
+* It shall be greater than or equal to zero.
+
+* It shall be less than or equal to `UINT32_MAX
+  `_.
 
 DESCRIPTION:
 The value of this configuration option defines the maximum blocks per write
@@ -225,7 +246,8 @@ DEFAULT VALUE:
 
 VALUE CONSTRAINTS:
 The value of this configuration option shall be a valid Classic API task
-priority.  The set of valid task priorities is scheduler-specific.
+priority.  The set of valid task priorities depends on the scheduler
+configuration.
 
 DESCRIPTION:
 The value of this configuration option defines the read-ahead task 
priority.
@@ -255,15 +277,16 @@ VALUE CONSTRAINTS:
 The value of this configuration option shall satisfy all of the 

Re: [PATCH] bsps/shared/ofw: Fix coverity defects

[Niteesh G. S.]

On Thu, Apr 29, 2021 at 12:50 AM Gedare Bloom  wrote:

> On Wed, Apr 28, 2021 at 11:30 AM G S Niteesh Babu 
> wrote:
> >
> > This patch adds asserts to fix coverity defects
> > 1) CID 1474437 (Out-of-bounds access)
> > 2) CID 1474436 (Out-of-bounds access)
> >
> > From manual inspection, out of bounds access cannot occur due to
> > bounds checking but coverity fails to detect the checks.
> > We are adding asserts as a secondary check.
> > ---
> >  bsps/shared/ofw/ofw.c | 12 +++-
> >  1 file changed, 11 insertions(+), 1 deletion(-)
> >
> > diff --git a/bsps/shared/ofw/ofw.c b/bsps/shared/ofw/ofw.c
> > index f4b8b63931..808fa85d81 100644
> > --- a/bsps/shared/ofw/ofw.c
> > +++ b/bsps/shared/ofw/ofw.c
> > @@ -42,6 +42,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >
> >  static void *fdtp = NULL;
> >
> > @@ -186,6 +187,7 @@ ssize_t rtems_ofw_get_prop(
> >const void *prop;
> >int offset;
> >int len;
> > +  int copy_len;
> >uint32_t cpuid;
> >
> >offset = rtems_fdt_phandle_to_offset(node);
> > @@ -226,7 +228,9 @@ ssize_t rtems_ofw_get_prop(
> >  return -1;
> >}
> >
> > -  bcopy(prop, buf, MIN(len, bufsize));
> > +  copy_len = MIN(len, bufsize);
> > +  _Assert(copy_len <= bufsize);
> > +  memmove(prop, buf, copy_len);
> >
> >return len;
> >  }
> > @@ -637,6 +641,12 @@ int rtems_ofw_get_reg(
> >  range.child_bus = fdt32_to_cpu(ptr[j].child_bus);
> >  range.size = fdt32_to_cpu(ptr[j].size);
> >
> > +/*
> > + * buf[i + 1] should upperbound the access for buf[i].
> > + * Thus by making sure buf[i + 1] <= (buf + size) we
> > + * can be sure buf[i] will always be inbounds.
> > + */
> > +_Assert(buf[i + 1] <= (buf + size));
> This looks suspect. It can make an out-of-bounds read access I think. How
> about
> _Assert(i < size);
> Is that equivalent?
>
No that won't work because size is the length of the buffer in bytes. I
right thing would be
_Assert(i < nregs) where nregs = size / sizeof(rtems_ofw_reg)
but I don't think adding this will make any change.
BTW what makes you suspect that it can still make an out-of-bounds access?

>
> >  if (buf[i].start >= range.child_bus &&
> >  buf[i].start < range.child_bus + range.size) {
> >offset = range.parent_bus - range.child_bus;
> > --
> > 2.17.1
> >
> > ___
> > devel mailing list
> > devel@rtems.org
> > http://lists.rtems.org/mailman/listinfo/devel
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] pwdgrp.c: Removed unused variable

[Gedare Bloom]

ok

On Wed, Apr 28, 2021 at 2:25 PM Ryan Long  wrote:
>
> The 'sc' variable was originally storing the return value of mkdir().
> This was causing an issue, so it was changed to make it to where we
> ignored the return value with (void). The 'sc' variable was left in
> by mistake.
> ---
>  cpukit/libcsupport/src/pwdgrp.c | 2 --
>  1 file changed, 2 deletions(-)
>
> diff --git a/cpukit/libcsupport/src/pwdgrp.c b/cpukit/libcsupport/src/pwdgrp.c
> index aac31f4..d686829 100644
> --- a/cpukit/libcsupport/src/pwdgrp.c
> +++ b/cpukit/libcsupport/src/pwdgrp.c
> @@ -63,8 +63,6 @@ static void init_file(const char *name, const char *content)
>   */
>  static void pwdgrp_init(void)
>  {
> -  int sc;
> -
>/*
> * Do the best to create this directory.
> *
> --
> 1.8.3.1
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: tcpreplay for testing network stacks

[Vijay Kumar Banerjee]

On Wed, Apr 28, 2021 at 3:27 PM Chris Johns  wrote:
>
>
>
> On 29/4/21 3:00 am, Vijay Kumar Banerjee wrote:
> > On Wed, Apr 28, 2021 at 10:49 AM Christian Mauderer  
> > wrote:
> >>
> >> Hello Vijay,
> >>
> >> On 28/04/2021 18:25, Vijay Kumar Banerjee wrote:
> >>> On Wed, Apr 28, 2021 at 12:41 AM Christian MAUDERER
> >>>  wrote:
> 
>  Hello Vijay,
> 
>  Am 27.04.21 um 18:48 schrieb Vijay Kumar Banerjee:
> > Hi,
> >
> > I came across the tcpreplay tool and it looks like a nice tool for
> > testing the network stacks. It can be used to capture network traffic
> > and then play it back, this will help with testing the network packets
> > from different network stacks.
> 
>  Sounds like an interesting tool.
> 
> >
> > My proposal is to add the tcpreply as a host-side tool in rtems-tools
> > and use it with the network interface where the network application is
> > running. The only issue that I see with the whole idea is that the
> > tcpreplay is GPLv3 licensed. Will that be compatible for rtems-tools?
> > The github repository says that it's compatible with UNIX and Windows
> > with cygwin.
> 
>  The more difficult problem could be the missing Mac and FreeBSD support.
> 
> >>> That's a good point.
> >>>
>  What would be the advantage of having tcpreply in rtems-tools? Do you
>  want to use it for automated tests?
> 
> >>> Yes. I was thinking about capturing the pcap format packets in
> >>> temporary files and then running tcpreplay to check for any network
> >>> issues. I haven't planned exactly how that will be implemented but
> >>> roughly this is the idea.
> >>>
> >>
> >> In what form would you automate that? Some test case in RTEMS or some
> >> special repository? I assume that you need some special setup for
> >> specific (simulator) targets anyway, don't you? So a general purpose
> >> test for all targets will be difficult.
> >>
> > I was not thinking about a special repository. It would be nice to
> > have it as test case or as an rtems-test config where the script will
> > capture the packets and feed them to tcpreplay.
>
> Capture from where? How do these traces deal with the differences in networks?
more tools :). What I was attempting is tcpdump to get the pcap and
then tcpreplay. I was basically in search of some way to effectively
test the network stacks.

> Does tcpreply rewrite various fields, for example a DHCP server response? I
> suspect it does not.
>
I'm not sure.

> Tcpreplay may work out to be a good tool we use but I think there needs to be
> some more ground work to see if you can "virtualize" a network. If you can do
> this you control the arena the devices operate in and all the characteristics
> and then play back would be possible and portable.
>
> VDE may be an interesting part of this. I seem to remember it has a DHCP 
> server
> so if you use this with a tap that VDE manages rtems-test could use that 
> interface.
>
That sounds like a great idea.

> A tricky area to look into is if a VDE port can map to a physical port? If 
> this
> can be done you could mix simulation and real hardware and that would be 
> amazing
> to have.
>
I'll search about this.


Thanks for the great ideas, I'm indeed getting some direction.

Best regards,
Vijay
> >> If it is about testing the stacks and not the drivers, it might would be
> >> possible to write some kind of dummy network driver that can read pcap
> >> format (or some other raw packet format) directly and hands the packets
> >> to the network stack. Such a driver maybe could even provide packets to
> >> a test frame again so that you can check responses.
> >>
> > The objective is to test the stacks. The dummy network driver sounds
> > like a great idea, thanks. I'll explore this direction more.
>
> I prefer real drivers are used as it lets us extend testing to VLAN and
> multicast (driver hashes and filter testing).
>
> A solution needs to find a suitable lowest common denominator. This means
> hardware and simulation and possibly the different networking stack options 
> we have.
>
> Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: tcpreplay for testing network stacks

[Vijay Kumar Banerjee]

On Wed, Apr 28, 2021 at 3:26 PM Chris Johns  wrote:
>
> On 29/4/21 2:31 am, Vijay Kumar Banerjee wrote:
> > On Wed, Apr 28, 2021 at 12:45 AM Chris Johns  wrote:
> >>
> >> On 28/4/21 2:48 am, Vijay Kumar Banerjee wrote:
> >>> I came across the tcpreplay tool and it looks like a nice tool for 
> >>> testing the
> >>> network stacks. It can be used to capture network traffic and then play 
> >>> it back,
> >>> this will help with testing the network packets from different network 
> >>> stacks.
> >>>
> >>> My proposal is to add the tcpreply as a host-side tool in rtems-tools and 
> >>> use it
> >>> with the network interface where the network application is running. The 
> >>> only
> >>> issue that I see with the whole idea is that the tcpreplay is GPLv3 
> >>> licensed.
> >>> Will that be compatible for rtems-tools? The github repository says that 
> >>> it's
> >>> compatible with UNIX and Windows with cygwin.
> >>>
> >>> Source repository:https://github.com/appneta/tcpreplay
> >>> 
> >>>
> >>> Thoughts and suggestions are much appreciated.
> >>
> >> It is GPLv3 so it cannot be imported as source. It can be referenced as a
> >> command if available for the host.
> >>
> > Ok.
> >
> >> I also suggest you investigate VDE with qemu. This is what I use to avoid 
> >> being
> >> root.
> >>
> > VDE looks great, I haven't tried it before. Thanks for the suggestion!
> > I'll try this out.
>
> No problem. Amar put me on to it years ago. I like it because I can run a few
> qemu networked sessions and I do not need to be root to do this. My host set 
> up
> is simple...
>
> From /etc/rc.conf:
>
> cloned_interfaces="bridge0 tap0 tap1 tap2"
> autobridge_interfaces="bridge0"
> ifconfig_bridge0="inet 10.10.5.2 netmask 255.255.255.0"
> autobridge_bridge0="re0.3 tap0 tap1 tap2"
>
> $ cat vde-start
> #! /bin/sh
> #
> # vdeterm /tmp/mgmt1
> #
> sysctl net.link.tap.user_open=1
> sysctl net.link.tap.up_on_open=1
> chmod 660 /dev/tap0
> vde_switch -d -s /tmp/vde1 -M /tmp/mgmt1 -tap tap0 -m 660 --mgmtmode 660
>
> Note, I internally run a bridge that VDE attaches to and all this is layer 2.
> The bridge is connected to a VLAN my engineering network runs on. You have to
> expect varying levels of complexity in user networks.
>
Thank you for the detailed configuration. It certainly looks nicer
compared to running wireshark using root.

> > Can write some rtems-test recipes with VDE to
> > automate the run? will that be feasible/possible?
>
> This depends on the type of testing you are looking to perform and the type of
> network architecture you are considering. My set up lets a qemu session see my
> network. I am bridging across it via a single tap that is created when the OS
> boots. I have attached some slides I put together last year on this topic.
>
The slides are interesting, thanks.

> The challenge is keeping the network infrastructure needed to a minimum, a
> simple configuration, support for hardware and simulation targets and agnostic
> network support.
>
I would certainly need to try it out for some manual runs first and
then I might start to look at how can we come up with a minimal
configuration for the automated testing.


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

Re: tcpreplay for testing network stacks

[Chris Johns]

On 29/4/21 3:00 am, Vijay Kumar Banerjee wrote:
> On Wed, Apr 28, 2021 at 10:49 AM Christian Mauderer  
> wrote:
>>
>> Hello Vijay,
>>
>> On 28/04/2021 18:25, Vijay Kumar Banerjee wrote:
>>> On Wed, Apr 28, 2021 at 12:41 AM Christian MAUDERER
>>>  wrote:

 Hello Vijay,

 Am 27.04.21 um 18:48 schrieb Vijay Kumar Banerjee:
> Hi,
>
> I came across the tcpreplay tool and it looks like a nice tool for
> testing the network stacks. It can be used to capture network traffic
> and then play it back, this will help with testing the network packets
> from different network stacks.

 Sounds like an interesting tool.

>
> My proposal is to add the tcpreply as a host-side tool in rtems-tools
> and use it with the network interface where the network application is
> running. The only issue that I see with the whole idea is that the
> tcpreplay is GPLv3 licensed. Will that be compatible for rtems-tools?
> The github repository says that it's compatible with UNIX and Windows
> with cygwin.

 The more difficult problem could be the missing Mac and FreeBSD support.

>>> That's a good point.
>>>
 What would be the advantage of having tcpreply in rtems-tools? Do you
 want to use it for automated tests?

>>> Yes. I was thinking about capturing the pcap format packets in
>>> temporary files and then running tcpreplay to check for any network
>>> issues. I haven't planned exactly how that will be implemented but
>>> roughly this is the idea.
>>>
>>
>> In what form would you automate that? Some test case in RTEMS or some
>> special repository? I assume that you need some special setup for
>> specific (simulator) targets anyway, don't you? So a general purpose
>> test for all targets will be difficult.
>>
> I was not thinking about a special repository. It would be nice to
> have it as test case or as an rtems-test config where the script will
> capture the packets and feed them to tcpreplay.

Capture from where? How do these traces deal with the differences in networks?
Does tcpreply rewrite various fields, for example a DHCP server response? I
suspect it does not.

Tcpreplay may work out to be a good tool we use but I think there needs to be
some more ground work to see if you can "virtualize" a network. If you can do
this you control the arena the devices operate in and all the characteristics
and then play back would be possible and portable.

VDE may be an interesting part of this. I seem to remember it has a DHCP server
so if you use this with a tap that VDE manages rtems-test could use that 
interface.

A tricky area to look into is if a VDE port can map to a physical port? If this
can be done you could mix simulation and real hardware and that would be amazing
to have.

>> If it is about testing the stacks and not the drivers, it might would be
>> possible to write some kind of dummy network driver that can read pcap
>> format (or some other raw packet format) directly and hands the packets
>> to the network stack. Such a driver maybe could even provide packets to
>> a test frame again so that you can check responses.
>>
> The objective is to test the stacks. The dummy network driver sounds
> like a great idea, thanks. I'll explore this direction more.

I prefer real drivers are used as it lets us extend testing to VLAN and
multicast (driver hashes and filter testing).

A solution needs to find a suitable lowest common denominator. This means
hardware and simulation and possibly the different networking stack options we 
have.

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

Re: tcpreplay for testing network stacks

[Chris Johns]

On 29/4/21 2:31 am, Vijay Kumar Banerjee wrote:
> On Wed, Apr 28, 2021 at 12:45 AM Chris Johns  wrote:
>>
>> On 28/4/21 2:48 am, Vijay Kumar Banerjee wrote:
>>> I came across the tcpreplay tool and it looks like a nice tool for testing 
>>> the
>>> network stacks. It can be used to capture network traffic and then play it 
>>> back,
>>> this will help with testing the network packets from different network 
>>> stacks.
>>>
>>> My proposal is to add the tcpreply as a host-side tool in rtems-tools and 
>>> use it
>>> with the network interface where the network application is running. The 
>>> only
>>> issue that I see with the whole idea is that the tcpreplay is GPLv3 
>>> licensed.
>>> Will that be compatible for rtems-tools? The github repository says that 
>>> it's
>>> compatible with UNIX and Windows with cygwin.
>>>
>>> Source repository:https://github.com/appneta/tcpreplay
>>> 
>>>
>>> Thoughts and suggestions are much appreciated.
>>
>> It is GPLv3 so it cannot be imported as source. It can be referenced as a
>> command if available for the host.
>>
> Ok.
> 
>> I also suggest you investigate VDE with qemu. This is what I use to avoid 
>> being
>> root.
>>
> VDE looks great, I haven't tried it before. Thanks for the suggestion!
> I'll try this out. 

No problem. Amar put me on to it years ago. I like it because I can run a few
qemu networked sessions and I do not need to be root to do this. My host set up
is simple...

>From /etc/rc.conf:

cloned_interfaces="bridge0 tap0 tap1 tap2"
autobridge_interfaces="bridge0"
ifconfig_bridge0="inet 10.10.5.2 netmask 255.255.255.0"
autobridge_bridge0="re0.3 tap0 tap1 tap2"

$ cat vde-start
#! /bin/sh
#
# vdeterm /tmp/mgmt1
#
sysctl net.link.tap.user_open=1
sysctl net.link.tap.up_on_open=1
chmod 660 /dev/tap0
vde_switch -d -s /tmp/vde1 -M /tmp/mgmt1 -tap tap0 -m 660 --mgmtmode 660

Note, I internally run a bridge that VDE attaches to and all this is layer 2.
The bridge is connected to a VLAN my engineering network runs on. You have to
expect varying levels of complexity in user networks.

> Can write some rtems-test recipes with VDE to
> automate the run? will that be feasible/possible?

This depends on the type of testing you are looking to perform and the type of
network architecture you are considering. My set up lets a qemu session see my
network. I am bridging across it via a single tap that is created when the OS
boots. I have attached some slides I put together last year on this topic.

The challenge is keeping the network infrastructure needed to a minimum, a
simple configuration, support for hardware and simulation targets and agnostic
network support.

Chris


RTEMS Network Testing.pdf
Description: Adobe PDF document
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Issues with rtems_waf on Windows 10 with gccdeps module

[Chris Johns]

On 28/4/21 7:59 pm, Robin Müller wrote:
> I think the following commit in rtems_waf breaks the waf build on Windows 10:
> 
> commit 096372fc4504730e50b51b952ce47ca603b35f01
> Author: Chris Johns mailto:chr...@rtems.org>>
> Date:   Thu Oct 10 17:43:11 2019 +1100
> 
>     Use gccdeps for dependency scanning.
> 
> I get the error that RTEMS is not able to find the rtems.h file in a certain
> directory when building the simple quick start application. The error does not
> occur on commits before that. I tried to run waf both in the WIndows CMD and 
> in
> MinGW64, it is problematic for both.

Could you please update your local version with ...

https://gitlab.com/ita1024/waf/-/blob/master/waflib/extras/gccdeps.py

... and report back how that goes?

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

[PATCH] pwdgrp.c: Removed unused variable

[Ryan Long]

The 'sc' variable was originally storing the return value of mkdir().
This was causing an issue, so it was changed to make it to where we
ignored the return value with (void). The 'sc' variable was left in
by mistake.
---
 cpukit/libcsupport/src/pwdgrp.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/cpukit/libcsupport/src/pwdgrp.c b/cpukit/libcsupport/src/pwdgrp.c
index aac31f4..d686829 100644
--- a/cpukit/libcsupport/src/pwdgrp.c
+++ b/cpukit/libcsupport/src/pwdgrp.c
@@ -63,8 +63,6 @@ static void init_file(const char *name, const char *content)
  */
 static void pwdgrp_init(void)
 {
-  int sc;
-
   /*
* Do the best to create this directory.
*
-- 
1.8.3.1

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

Re: [PATCH] bsps/shared/ofw: Fix coverity defects

[Gedare Bloom]

On Wed, Apr 28, 2021 at 11:30 AM G S Niteesh Babu  wrote:
>
> This patch adds asserts to fix coverity defects
> 1) CID 1474437 (Out-of-bounds access)
> 2) CID 1474436 (Out-of-bounds access)
>
> From manual inspection, out of bounds access cannot occur due to
> bounds checking but coverity fails to detect the checks.
> We are adding asserts as a secondary check.
> ---
>  bsps/shared/ofw/ofw.c | 12 +++-
>  1 file changed, 11 insertions(+), 1 deletion(-)
>
> diff --git a/bsps/shared/ofw/ofw.c b/bsps/shared/ofw/ofw.c
> index f4b8b63931..808fa85d81 100644
> --- a/bsps/shared/ofw/ofw.c
> +++ b/bsps/shared/ofw/ofw.c
> @@ -42,6 +42,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>
>  static void *fdtp = NULL;
>
> @@ -186,6 +187,7 @@ ssize_t rtems_ofw_get_prop(
>const void *prop;
>int offset;
>int len;
> +  int copy_len;
>uint32_t cpuid;
>
>offset = rtems_fdt_phandle_to_offset(node);
> @@ -226,7 +228,9 @@ ssize_t rtems_ofw_get_prop(
>  return -1;
>}
>
> -  bcopy(prop, buf, MIN(len, bufsize));
> +  copy_len = MIN(len, bufsize);
> +  _Assert(copy_len <= bufsize);
> +  memmove(prop, buf, copy_len);
>
>return len;
>  }
> @@ -637,6 +641,12 @@ int rtems_ofw_get_reg(
>  range.child_bus = fdt32_to_cpu(ptr[j].child_bus);
>  range.size = fdt32_to_cpu(ptr[j].size);
>
> +/*
> + * buf[i + 1] should upperbound the access for buf[i].
> + * Thus by making sure buf[i + 1] <= (buf + size) we
> + * can be sure buf[i] will always be inbounds.
> + */
> +_Assert(buf[i + 1] <= (buf + size));
This looks suspect. It can make an out-of-bounds read access I think. How about
_Assert(i < size);
Is that equivalent?

>  if (buf[i].start >= range.child_bus &&
>  buf[i].start < range.child_bus + range.size) {
>offset = range.parent_bus - range.child_bus;
> --
> 2.17.1
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Write the BSP for ARM Versatile Express device

[Đức Anh]

Hi,

Do you have any executables from anywhere that run on the simulator in the
> configuration you intend for RTEMS to use?


Sorry, I forgot to answer your question. Actually, my goal is just to
make Rtems up and run in the Gem5 simulator. And then I will study the task
preemption part of Rtems, try to record the preemption overhead time, and
the task execution order. So, any configuration is ok, as long as it is
Arm or Aarch64 arch, Cortex-A series.

I tried to wrap my head around the fvp BSP, since it is the closest one to
the VExpress device I try to make. The bspcortexr52.yml config file looks
like it does nothing specific to the BSP, only includes (common for ARM?)
dependencies, doesn't it?

Best regards,
Duc Anh

Vào Th 4, 21 thg 4, 2021 vào lúc 15:25 Joel Sherrill  đã
viết:

>
>
> On Wed, Apr 21, 2021, 5:32 AM Đức Anh  wrote:
>
>> Hi Gedare,
>>
>> For the last few days, I am reading the rtems source code, trying to
>> understand the build system, how a bsp is built. I just has a few questions:
>> - it seems like the configure.ac and Makefile.am for each BSP
>> (c/src/lib/libbsp/) is separate from the BSP source code (bsps/). However
>> not all BSP has configure.ac and Makefile.am, for example, the FVP BSP
>> you said. What is the difference here?
>> - my speculation right now is to create a new folder in c/src/lib/libbsp/
>> for the VExpress device, put the configure.ac and Makefile.am in and put
>> the source file in bsps/ ?
>>
>
> First, that's the old build system and separate so it will be easier to
> remove. It reflects an older organisation of the source tree.  The new
> build system is waf and under spec/ at the top of the tree. Please use that
> for new work.
>
> Next, the BSPs have families and variants within a family. The directory
> is the family and there are configuration files to build variants within
> the family. The Zynq bsp family has a handful of variants. Run rtems-bsps
> from the top of the tree for a list.
>
> Do you have any executables from anywhere that run on the simulator in the
> configuration you intend for RTEMS to use?
>
> Focus on uniprocessor and getting hello to run first. But the devel@ list
> is a better resource.
>
>>
>> Best regards,
>> Duc Anh
>>
>>
>> Vào Th 4, 14 thg 4, 2021 vào lúc 12:53 Gedare Bloom 
>> đã viết:
>>
>>> Hi Duc,
>>>
>>> On Tue, Apr 13, 2021 at 8:57 AM Đức Anh  wrote:
>>> >
>>> > Dear all,
>>> >
>>> > I want to develop a BSP for ARM Versatile Express platform. My final
>>> purpose is to run Gem5 simulation using RTEMS as the kernel. Now Gem5 only
>>> model Versatile Express device, and I can see RTEMS does not have a BSP for
>>> it yet.
>>> >
>>> > More specifically, the machine type modelled in Gem5 is:
>>> > - Arm Motherboard Express uATX (V2M-P1)
>>> > - The memory map is based on Versatile Express RS1, with RS2 extension
>>> > - Arm CoreTile Express A15x2 (V2P-CA15) as daughterboard. It contains
>>> Cortex-A15 CPU.
>>> >
>>> > In the past, the Realview-pbx-a9 BSP used to run successfully in Gem5,
>>> when they still supported realview machine type. It is not the case now. So
>>> I guess I can reuse the CPU related code in realview-pbx-a9 and just write
>>> new code for the BSP ?
>>> >
>>> Well, the realview pbx a9 is a cortex-a9 device and not an a15. Plus,
>>> I guess the vexpress will have some differences in how it deals with
>>> interrupts and maybe messaging given its tiled architecture? I don't
>>> know too much about it. But, your best bet is probably to try to start
>>> with the FVP bsp, which was only added about 5 months ago and supports
>>> just a Cortex-R52 right now, but probably adding the vexpress RS1
>>> memory map with the V2P-CA15 is the right way for you to go.
>>>
>>> > I am new to RTEMS so I need some help. Which direction should I head
>>> for?
>>> >
>>> Join the devel@rtems.org mailing list for technical email discussions
>>> regarding hacking within RTEMS proper. (The "users" mailing list is a
>>> bit more for people trying to develop/maintain their application
>>> software using RTEMS mostly *fingers crossed* out of the box.) I would
>>> strongly recommend that you get started by following through our
>>> tutorials to get a feel for the tools and development environment:
>>> https://docs.rtems.org/branches/master/user/start/index.html
>>> Read carefully and don't skip steps, or you probably miss something
>>> important that you won't figure out until a couple hours later and
>>> have to redo everything. Since you plan new development, you should
>>> use the `master` branch of RTEMS with the `master` branch of the
>>> rtems-source-builder to build your cross-compiler toolchain. This is
>>> referred to as version '6' although it is not yet a released version.
>>>
>>> Right now we have a lot of new faces on devel@ because of the Google
>>> Summer of Code, so you'll find a lot of other people with questions
>>> and answers about how to get started etc. I would recommend you also
>>> do our GSoC Getting Started 

[PATCH rtems-lwip v2] STM32 lwIP addition

[Robin Mueller]

This patch adds the STM32H7 / NUCLEO-H743ZI lwIP port.
It also improves the architecture to make integration
of new BSPs easier. The patch continues the wscript file to
allow installing the lwIP support similar to how a RTEMS
BSP is installed.

https://github.com/rmspacefish/rtems-stm32-lwip is a self-contained
repository to test the lwIP integration for the arm/stm32h7
and arm/nucleo-h743zi BSP. The repository README specifies
how to build the RTEMS lwIP support and install it at a specified
prefix location.

The STM32 port includes the LAN driver (lan8742.c), the
primary port functions in ethernetif.c and some application code
taken from CubeH7, which can serve as a starting point for
implementations and was also tailored to RTEMS.

The common source file were refactored to be more generic and independent
of the used BSP.

This patch includes corrections from the code review by Gedare Bloom.

Please note that any merges need to be held off until some licensing issues
with STM concerning the SLA0044 license on example files are resolved.
---
 .gitignore|   6 +
 .gitmodules   |   1 +
 README.md |  32 +
 lwip-to-rtems.py  |   0
 lwip.py   | 182 -
 .../drivers/{eth_lwip.c => rtems_lwip.c}  | 187 +++--
 .../drivers/{eth_lwip.h => rtems_lwip.h}  |  92 ++-
 .../{eth_lwip_default.h => rtems_lwip_conf.h} |  30 +-
 lwip/ports/drivers/stm32h7/app_dhcp.c | 208 +
 lwip/ports/drivers/stm32h7/app_ethernet.c | 191 +
 lwip/ports/drivers/stm32h7/ethernetif.c   | 748 ++
 .../stm32h7/include/rtems_lwip/app_dhcp.h |  51 ++
 .../stm32h7/include/rtems_lwip/app_ethernet.h |  64 ++
 .../stm32h7/include/rtems_lwip/ethernetif.h   |  59 ++
 lwip/ports/drivers/stm32h7/lan8742.c  | 664 
 lwip/ports/drivers/stm32h7/lan8742.h  | 448 +++
 lwip/ports/drivers/stm32h7/port_conf.h|  44 ++
 .../stm32h7/template/lwipopts_template.h  | 292 +++
 .../include/rtems_lwip}/tms570_netif.h|  31 +
 .../ports/drivers/{ => tms570}/phy_dp83848h.c |   0
 .../ports/drivers/{ => tms570}/phy_dp83848h.h |   0
 .../tms570/template/lwipopts_template.h   |  75 ++
 lwip/ports/drivers/{ => tms570}/ti_drv_emac.h |   0
 lwip/ports/drivers/{ => tms570}/ti_drv_mdio.h |   0
 lwip/ports/drivers/{ => tms570}/tms570_emac.h |   0
 .../ports/drivers/{ => tms570}/tms570_netif.c |  11 +-
 lwip/ports/os/rtems/arch/cc.h |   3 +
 lwip/ports/os/rtems/arch/sys_arch.c   |  31 +-
 lwip/ports/os/rtems/arch/sys_arch.h   |  18 +-
 lwip/ports/os/rtems/defaults/lwipopts.h   |  37 +
 lwip/src/include/lwip/sys.h   |   1 -
 lwip/{ports/os => test}/lwipopts.h|   0
 wscript   |   2 +
 33 files changed, 3348 insertions(+), 160 deletions(-)
 create mode 100644 README.md
 mode change 100755 => 100644 lwip-to-rtems.py
 rename lwip/ports/drivers/{eth_lwip.c => rtems_lwip.c} (56%)
 rename lwip/ports/drivers/{eth_lwip.h => rtems_lwip.h} (55%)
 rename lwip/ports/drivers/{eth_lwip_default.h => rtems_lwip_conf.h} (68%)
 create mode 100644 lwip/ports/drivers/stm32h7/app_dhcp.c
 create mode 100644 lwip/ports/drivers/stm32h7/app_ethernet.c
 create mode 100644 lwip/ports/drivers/stm32h7/ethernetif.c
 create mode 100644 lwip/ports/drivers/stm32h7/include/rtems_lwip/app_dhcp.h
 create mode 100644 lwip/ports/drivers/stm32h7/include/rtems_lwip/app_ethernet.h
 create mode 100644 lwip/ports/drivers/stm32h7/include/rtems_lwip/ethernetif.h
 create mode 100644 lwip/ports/drivers/stm32h7/lan8742.c
 create mode 100644 lwip/ports/drivers/stm32h7/lan8742.h
 create mode 100644 lwip/ports/drivers/stm32h7/port_conf.h
 create mode 100644 lwip/ports/drivers/stm32h7/template/lwipopts_template.h
 rename lwip/ports/drivers/{ => tms570/include/rtems_lwip}/tms570_netif.h (74%)
 rename lwip/ports/drivers/{ => tms570}/phy_dp83848h.c (100%)
 rename lwip/ports/drivers/{ => tms570}/phy_dp83848h.h (100%)
 create mode 100644 lwip/ports/drivers/tms570/template/lwipopts_template.h
 rename lwip/ports/drivers/{ => tms570}/ti_drv_emac.h (100%)
 rename lwip/ports/drivers/{ => tms570}/ti_drv_mdio.h (100%)
 rename lwip/ports/drivers/{ => tms570}/tms570_emac.h (100%)
 rename lwip/ports/drivers/{ => tms570}/tms570_netif.c (99%)
 create mode 100644 lwip/ports/os/rtems/defaults/lwipopts.h
 rename lwip/{ports/os => test}/lwipopts.h (100%)

diff --git a/.gitignore b/.gitignore
index 618d791..91a3a03 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,4 +1,10 @@
+# Python
 __pycache__
+
+# Waf
 .lock-waf*
 .waf*
+/*.pyc
+
+# Builds
 build/
diff --git a/.gitmodules b/.gitmodules
index 4ea46da..a98aac6 100644
--- a/.gitmodules
+++ b/.gitmodules
@@ -4,3 +4,4 @@
 [submodule "rtems_waf"]
path = rtems_waf
url = git://git.rtems.org/rtems_waf.git
+
diff --git 

[PATCH] bsps/shared/ofw: Fix coverity defects

[G S Niteesh Babu]

This patch adds asserts to fix coverity defects
1) CID 1474437 (Out-of-bounds access)
2) CID 1474436 (Out-of-bounds access)

>From manual inspection, out of bounds access cannot occur due to
bounds checking but coverity fails to detect the checks.
We are adding asserts as a secondary check.
---
 bsps/shared/ofw/ofw.c | 12 +++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/bsps/shared/ofw/ofw.c b/bsps/shared/ofw/ofw.c
index f4b8b63931..808fa85d81 100644
--- a/bsps/shared/ofw/ofw.c
+++ b/bsps/shared/ofw/ofw.c
@@ -42,6 +42,7 @@
 #include 
 #include 
 #include 
+#include 
 
 static void *fdtp = NULL;
 
@@ -186,6 +187,7 @@ ssize_t rtems_ofw_get_prop(
   const void *prop;
   int offset;
   int len;
+  int copy_len;
   uint32_t cpuid;
 
   offset = rtems_fdt_phandle_to_offset(node);
@@ -226,7 +228,9 @@ ssize_t rtems_ofw_get_prop(
 return -1;
   }
 
-  bcopy(prop, buf, MIN(len, bufsize));
+  copy_len = MIN(len, bufsize);
+  _Assert(copy_len <= bufsize);
+  memmove(prop, buf, copy_len);
 
   return len;
 }
@@ -637,6 +641,12 @@ int rtems_ofw_get_reg(
 range.child_bus = fdt32_to_cpu(ptr[j].child_bus);
 range.size = fdt32_to_cpu(ptr[j].size);
 
+/*
+ * buf[i + 1] should upperbound the access for buf[i].
+ * Thus by making sure buf[i + 1] <= (buf + size) we
+ * can be sure buf[i] will always be inbounds.
+ */
+_Assert(buf[i + 1] <= (buf + size));
 if (buf[i].start >= range.child_bus &&
 buf[i].start < range.child_bus + range.size) {
   offset = range.parent_bus - range.child_bus;
-- 
2.17.1

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

Re: tcpreplay for testing network stacks

[Vijay Kumar Banerjee]

On Wed, Apr 28, 2021 at 10:49 AM Christian Mauderer  wrote:
>
> Hello Vijay,
>
> On 28/04/2021 18:25, Vijay Kumar Banerjee wrote:
> > On Wed, Apr 28, 2021 at 12:41 AM Christian MAUDERER
> >  wrote:
> >>
> >> Hello Vijay,
> >>
> >> Am 27.04.21 um 18:48 schrieb Vijay Kumar Banerjee:
> >>> Hi,
> >>>
> >>> I came across the tcpreplay tool and it looks like a nice tool for
> >>> testing the network stacks. It can be used to capture network traffic
> >>> and then play it back, this will help with testing the network packets
> >>> from different network stacks.
> >>
> >> Sounds like an interesting tool.
> >>
> >>>
> >>> My proposal is to add the tcpreply as a host-side tool in rtems-tools
> >>> and use it with the network interface where the network application is
> >>> running. The only issue that I see with the whole idea is that the
> >>> tcpreplay is GPLv3 licensed. Will that be compatible for rtems-tools?
> >>> The github repository says that it's compatible with UNIX and Windows
> >>> with cygwin.
> >>
> >> The more difficult problem could be the missing Mac and FreeBSD support.
> >>
> > That's a good point.
> >
> >> What would be the advantage of having tcpreply in rtems-tools? Do you
> >> want to use it for automated tests?
> >>
> > Yes. I was thinking about capturing the pcap format packets in
> > temporary files and then running tcpreplay to check for any network
> > issues. I haven't planned exactly how that will be implemented but
> > roughly this is the idea.
> >
>
> In what form would you automate that? Some test case in RTEMS or some
> special repository? I assume that you need some special setup for
> specific (simulator) targets anyway, don't you? So a general purpose
> test for all targets will be difficult.
>
I was not thinking about a special repository. It would be nice to
have it as test case or as an rtems-test config where the script will
capture the packets and feed them to tcpreplay.

> If it is about testing the stacks and not the drivers, it might would be
> possible to write some kind of dummy network driver that can read pcap
> format (or some other raw packet format) directly and hands the packets
> to the network stack. Such a driver maybe could even provide packets to
> a test frame again so that you can check responses.
>
The objective is to test the stacks. The dummy network driver sounds
like a great idea, thanks. I'll explore this direction more.

> Best regards
>
> Christian
>
> >> Best regards
> >>
> >> Christian
> >>
> >>>
> >>> Source repository:https://github.com/appneta/tcpreplay
> >>> 
> >>>
> >>> Thoughts and suggestions are much appreciated.
> >>>
> >>>
> >>> Best regards,
> >>> Vijay
> >>>
> >>> ___
> >>> devel mailing list
> >>> devel@rtems.org
> >>> http://lists.rtems.org/mailman/listinfo/devel
> >>>
> >>
> >> --
> >> 
> >> embedded brains GmbH
> >> Herr Christian MAUDERER
> >> Dornierstr. 4
> >> 82178 Puchheim
> >> Germany
> >> email: christian.maude...@embedded-brains.de
> >> phone: +49-89-18 94 741 - 18
> >> fax:   +49-89-18 94 741 - 08
> >>
> >> Registergericht: Amtsgericht München
> >> Registernummer: HRB 157899
> >> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
> >> Unsere Datenschutzerklärung finden Sie hier:
> >> https://embedded-brains.de/datenschutzerklaerung/
> > ___
> > 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: tcpreplay for testing network stacks

[Christian Mauderer]

Hello Vijay,

On 28/04/2021 18:25, Vijay Kumar Banerjee wrote:

On Wed, Apr 28, 2021 at 12:41 AM Christian MAUDERER
 wrote:


Hello Vijay,

Am 27.04.21 um 18:48 schrieb Vijay Kumar Banerjee:

Hi,

I came across the tcpreplay tool and it looks like a nice tool for
testing the network stacks. It can be used to capture network traffic
and then play it back, this will help with testing the network packets
from different network stacks.


Sounds like an interesting tool.



My proposal is to add the tcpreply as a host-side tool in rtems-tools
and use it with the network interface where the network application is
running. The only issue that I see with the whole idea is that the
tcpreplay is GPLv3 licensed. Will that be compatible for rtems-tools?
The github repository says that it's compatible with UNIX and Windows
with cygwin.


The more difficult problem could be the missing Mac and FreeBSD support.


That's a good point.


What would be the advantage of having tcpreply in rtems-tools? Do you
want to use it for automated tests?


Yes. I was thinking about capturing the pcap format packets in
temporary files and then running tcpreplay to check for any network
issues. I haven't planned exactly how that will be implemented but
roughly this is the idea.



In what form would you automate that? Some test case in RTEMS or some 
special repository? I assume that you need some special setup for 
specific (simulator) targets anyway, don't you? So a general purpose 
test for all targets will be difficult.


If it is about testing the stacks and not the drivers, it might would be 
possible to write some kind of dummy network driver that can read pcap 
format (or some other raw packet format) directly and hands the packets 
to the network stack. Such a driver maybe could even provide packets to 
a test frame again so that you can check responses.


Best regards

Christian


Best regards

Christian



Source repository:https://github.com/appneta/tcpreplay


Thoughts and suggestions are much appreciated.


Best regards,
Vijay

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



--

embedded brains GmbH
Herr Christian MAUDERER
Dornierstr. 4
82178 Puchheim
Germany
email: christian.maude...@embedded-brains.de
phone: +49-89-18 94 741 - 18
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/

___
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: tcpreplay for testing network stacks

[Joel Sherrill]

On Wed, Apr 28, 2021 at 11:25 AM Vijay Kumar Banerjee 
wrote:

> On Wed, Apr 28, 2021 at 12:41 AM Christian MAUDERER
>  wrote:
> >
> > Hello Vijay,
> >
> > Am 27.04.21 um 18:48 schrieb Vijay Kumar Banerjee:
> > > Hi,
> > >
> > > I came across the tcpreplay tool and it looks like a nice tool for
> > > testing the network stacks. It can be used to capture network traffic
> > > and then play it back, this will help with testing the network packets
> > > from different network stacks.
> >
> > Sounds like an interesting tool.
>

Used to be BSD.

https://synfin.net/sock_stream/technology/code/tcpreplay/why-tcpreplay-went-gpl

Is there a BSD licensed fork out there?


> >
> > >
> > > My proposal is to add the tcpreply as a host-side tool in rtems-tools
> > > and use it with the network interface where the network application is
> > > running. The only issue that I see with the whole idea is that the
> > > tcpreplay is GPLv3 licensed. Will that be compatible for rtems-tools?
> > > The github repository says that it's compatible with UNIX and Windows
> > > with cygwin.
> >
> > The more difficult problem could be the missing Mac and FreeBSD support.
> >
> That's a good point.
>
> > What would be the advantage of having tcpreply in rtems-tools? Do you
> > want to use it for automated tests?
> >
> Yes. I was thinking about capturing the pcap format packets in
> temporary files and then running tcpreplay to check for any network
> issues. I haven't planned exactly how that will be implemented but
> roughly this is the idea.
>
> > Best regards
> >
> > Christian
> >
> > >
> > > Source repository:https://github.com/appneta/tcpreplay
> > > 
> > >
> > > Thoughts and suggestions are much appreciated.
> > >
> > >
> > > Best regards,
> > > Vijay
> > >
> > > ___
> > > devel mailing list
> > > devel@rtems.org
> > > http://lists.rtems.org/mailman/listinfo/devel
> > >
> >
> > --
> > 
> > embedded brains GmbH
> > Herr Christian MAUDERER
> > Dornierstr. 4
> > 82178 Puchheim
> > Germany
> > email: christian.maude...@embedded-brains.de
> > phone: +49-89-18 94 741 - 18
> > fax:   +49-89-18 94 741 - 08
> >
> > Registergericht: Amtsgericht München
> > Registernummer: HRB 157899
> > Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
> > Unsere Datenschutzerklärung finden Sie hier:
> > https://embedded-brains.de/datenschutzerklaerung/
> ___
> 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: tcpreplay for testing network stacks

[Vijay Kumar Banerjee]

On Wed, Apr 28, 2021 at 12:45 AM Chris Johns  wrote:
>
> On 28/4/21 2:48 am, Vijay Kumar Banerjee wrote:
> > I came across the tcpreplay tool and it looks like a nice tool for testing 
> > the
> > network stacks. It can be used to capture network traffic and then play it 
> > back,
> > this will help with testing the network packets from different network 
> > stacks.
> >
> > My proposal is to add the tcpreply as a host-side tool in rtems-tools and 
> > use it
> > with the network interface where the network application is running. The 
> > only
> > issue that I see with the whole idea is that the tcpreplay is GPLv3 
> > licensed.
> > Will that be compatible for rtems-tools? The github repository says that 
> > it's
> > compatible with UNIX and Windows with cygwin.
> >
> > Source repository:https://github.com/appneta/tcpreplay
> > 
> >
> > Thoughts and suggestions are much appreciated.
>
> It is GPLv3 so it cannot be imported as source. It can be referenced as a
> command if available for the host.
>
Ok.

> I also suggest you investigate VDE with qemu. This is what I use to avoid 
> being
> root.
>
VDE looks great, I haven't tried it before. Thanks for the suggestion!
I'll try this out. Can write some rtems-test recipes with VDE to
automate the run? will that be feasible/possible?


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

Re: tcpreplay for testing network stacks

[Vijay Kumar Banerjee]

On Wed, Apr 28, 2021 at 12:41 AM Christian MAUDERER
 wrote:
>
> Hello Vijay,
>
> Am 27.04.21 um 18:48 schrieb Vijay Kumar Banerjee:
> > Hi,
> >
> > I came across the tcpreplay tool and it looks like a nice tool for
> > testing the network stacks. It can be used to capture network traffic
> > and then play it back, this will help with testing the network packets
> > from different network stacks.
>
> Sounds like an interesting tool.
>
> >
> > My proposal is to add the tcpreply as a host-side tool in rtems-tools
> > and use it with the network interface where the network application is
> > running. The only issue that I see with the whole idea is that the
> > tcpreplay is GPLv3 licensed. Will that be compatible for rtems-tools?
> > The github repository says that it's compatible with UNIX and Windows
> > with cygwin.
>
> The more difficult problem could be the missing Mac and FreeBSD support.
>
That's a good point.

> What would be the advantage of having tcpreply in rtems-tools? Do you
> want to use it for automated tests?
>
Yes. I was thinking about capturing the pcap format packets in
temporary files and then running tcpreplay to check for any network
issues. I haven't planned exactly how that will be implemented but
roughly this is the idea.

> Best regards
>
> Christian
>
> >
> > Source repository:https://github.com/appneta/tcpreplay
> > 
> >
> > Thoughts and suggestions are much appreciated.
> >
> >
> > Best regards,
> > Vijay
> >
> > ___
> > devel mailing list
> > devel@rtems.org
> > http://lists.rtems.org/mailman/listinfo/devel
> >
>
> --
> 
> embedded brains GmbH
> Herr Christian MAUDERER
> Dornierstr. 4
> 82178 Puchheim
> Germany
> email: christian.maude...@embedded-brains.de
> phone: +49-89-18 94 741 - 18
> fax:   +49-89-18 94 741 - 08
>
> Registergericht: Amtsgericht München
> Registernummer: HRB 157899
> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
> Unsere Datenschutzerklärung finden Sie hier:
> https://embedded-brains.de/datenschutzerklaerung/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] STM32 lwIP addition

[Gedare Bloom]

Squash, and send with -v2

https://docs.rtems.org/branches/master/eng/vc-users.html#creating-a-patch

Use --subject-prefix="PATCH rtems-lwip"

We expect there will be things installed. It is expected only one
network stack will be installed in a given PREFIX. We haven't quite
gotten to the point of documenting that expectation yet. You're on the
bleeding edge :)

Thanks,
Gedare

On Wed, Apr 28, 2021 at 8:48 AM Robin Müller  wrote:
>
> I integrated most of your points and added waf support. The lwIP support can 
> now be installed like the RTEMS BSP with waf so the PKG Config generated by 
> the BSP installation can be reused.  It puts some folders like lwip / netif / 
> compat into the include path, I hope this is not problematic. I'll send the 
> updated patch with the disclaimer that there are still licensing issues to 
> resolve after cleaning up a bit.
>
> Kind Regards
> Robin
>
> On Wed, 28 Apr 2021 at 12:00, Robin Müller  wrote:
>>
>> Small correction: I changed the ethernetif.c file to be usable by all three 
>> major APIs.
>>
>> Kind Regards
>> Robin
>>
>> On Wed, 28 Apr 2021 at 11:55, Robin Müller  wrote:
>>>
>>> Should I provide the changes for the code review as a separate patch or 
>>> should I squash them again?
>>>
>>> Using the upstream unchanged is tricky because the code was taken from the 
>>> examples and these examples are always targeted towards a specific API.
>>> I changed the version to be usable by both APIs. I now applied the 
>>> __rtems__ preprocessor defines where applicable and moved the preprocessor 
>>> defines into a separate file.
>>>
>>> Kind Regards
>>> Robin
>>>
>>> On Tue, 27 Apr 2021 at 22:21, Gedare Bloom  wrote:

 On Tue, Apr 27, 2021 at 2:09 PM Gedare Bloom  wrote:
 >
 > On Tue, Apr 27, 2021 at 11:41 AM Robin Mueller
 >  wrote:
 > >

 I'm not sure what happened, it looks like my email client garbled the
 inline threaded reply. Hopefully my comments come through for you ok.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] STM32 lwIP addition

[Robin Müller]

I integrated most of your points and added waf support. The lwIP support
can now be installed like the RTEMS BSP with waf so the PKG Config
generated by the BSP installation can be reused.  It puts some folders like
lwip / netif / compat into the include path, I hope this is not
problematic. I'll send the updated patch with the disclaimer that there are
still licensing issues to resolve after cleaning up a bit.

Kind Regards
Robin

On Wed, 28 Apr 2021 at 12:00, Robin Müller 
wrote:

> Small correction: I changed the ethernetif.c file to be usable by all
> three major APIs.
>
> Kind Regards
> Robin
>
> On Wed, 28 Apr 2021 at 11:55, Robin Müller 
> wrote:
>
>> Should I provide the changes for the code review as a separate patch or
>> should I squash them again?
>>
>> Using the upstream unchanged is tricky because the code was taken from
>> the examples and these examples are always targeted towards a specific API.
>> I changed the version to be usable by both APIs. I now applied the
>> __rtems__ preprocessor defines where applicable and moved the preprocessor
>> defines into a separate file.
>>
>> Kind Regards
>> Robin
>>
>> On Tue, 27 Apr 2021 at 22:21, Gedare Bloom  wrote:
>>
>>> On Tue, Apr 27, 2021 at 2:09 PM Gedare Bloom  wrote:
>>> >
>>> > On Tue, Apr 27, 2021 at 11:41 AM Robin Mueller
>>> >  wrote:
>>> > >
>>>
>>> I'm not sure what happened, it looks like my email client garbled the
>>> inline threaded reply. Hopefully my comments come through for you ok.
>>>
>>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH] riscv/start: Startup sequence update.

[Somesh Deshmukh]

- The current startup sequence performs the call to the bsp_fdt_copy() and then
  performs memset to the BSS region. In bsp_fdt_copy(), RTEMS allocates
  memory for bsp_fdt_blob into BSS region which is yet to initialize. With
  current startup sequence, the bsp_fdt_blob is getting erased after memset.
  The proposed fix performs the BSS region memset operation and then performs a
  call to the bsp_fdt_copy().
---
 bsps/riscv/shared/start/start.S | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/bsps/riscv/shared/start/start.S b/bsps/riscv/shared/start/start.S
index 04a62a26ce..277760a388 100644
--- a/bsps/riscv/shared/start/start.S
+++ b/bsps/riscv/shared/start/start.S
@@ -74,17 +74,17 @@ SYM(_start):
LADDR   sp, _ISR_Stack_area_end
 #endif
 
+/* Clear .bss */
+LADDR  a0, bsp_section_bss_begin
+li a1, 0
+LADDR  a2, bsp_section_bss_size
+call   memset
+
 #ifdef BSP_START_COPY_FDT_FROM_U_BOOT
mv  a0, a1
callbsp_fdt_copy
 #endif
 
-   /* Clear .bss */
-   LADDR   a0, bsp_section_bss_begin
-   li  a1, 0
-   LADDR   a2, bsp_section_bss_size
-   callmemset
-
 #ifdef RTEMS_SMP
/* Give go to secondary processors */
LADDR   t0, .Lsecondary_processor_go
-- 
2.25.1

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

[PATCH] riscv/console: Updated the console-config.c file

[Somesh Deshmukh]

- Parsing the sub-node should be available generic not specific to Freedom
  Arty310 board. If we remove the Freedom Arty macro now, it will lose
  backward compatibility.The proposed change will retain the backward
  compatibility and also adds the necessary fix for parsing sub-node.

- Line 234 and 235 in riscv_console_probe() uses polled handlers for ns16550
  read and write while, the console_initialize function uses ns16550
  interrupt handler. Proposing a fix to make polled handlers consistant
  through out the console-config.c
---
 bsps/riscv/riscv/console/console-config.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/bsps/riscv/riscv/console/console-config.c 
b/bsps/riscv/riscv/console/console-config.c
index d962a5a418..f203f0be7d 100644
--- a/bsps/riscv/riscv/console/console-config.c
+++ b/bsps/riscv/riscv/console/console-config.c
@@ -91,7 +91,7 @@ static int riscv_get_console_node(const void *fdt)
 stdout_path = "";
   }
 
-#if RISCV_ENABLE_FRDME310ARTY_SUPPORT != 0
+#if ((RISCV_ENABLE_FRDME310ARTY_SUPPORT != 0) || 
(RISCV_CONSOLE_MAX_NS16550_DEVICES > 0))
   int root;
   int soc;
   root = fdt_path_offset(fdt, "/");
@@ -318,7 +318,7 @@ rtems_status_code console_initialize(
 
 rtems_termios_device_install(
   path,
-  _handler_interrupt,
+  _handler_polled,
   NULL,
   >base
 );
-- 
2.25.1

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

Re: [PATCH] posix: Use alias for pthread_self()

[Joel Sherrill]

On Wed, Apr 28, 2021 at 12:04 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

>
> On 28/04/2021 00:28, Joel Sherrill wrote:
> >
> >
> > On Tue, Apr 27, 2021, 11:24 AM Sebastian Huber
> >  > > wrote:
> >
> > On 27/04/2021 18:23, Gedare Bloom wrote:
> >
> > > PS: the git-rm is missing?
> > Oh, yes. I will fix this if Joel is happy with the change.
> >
> >
> > Can you set a breakpoint on it as pthread_self?
>
> Yes, this works:
>
> (gdb) b pthread_self
> Breakpoint 6 at 0x105fac: file ../../../cpukit/rtems/src/taskself.c,
> line 29.
> (gdb) c
> Continuing.
>
> Breakpoint 6, rtems_task_self () at ../../../cpukit/rtems/src/taskself.c:29
> 29 return _Thread_Get_executing()->Object.id;
> (gdb)
>
> (gdb) print pthread_self
> $1 = {rtems_id (void)} 0x105fa8 
>
> >
> > It is an odd case but I think I would rather have a score method and
> > both be aliases.
> I could add an _Thread_Self_id() with aliases rtems_task_self and
> pthread_self.
>

It's rather trivial but I would feel better about that. Is there an inline
method like this currently? I think there have been one at various
times across RTEMS history.

--joel

>
> --
> embedded brains GmbH
> Herr Sebastian HUBER
> Dornierstr. 4
> 82178 Puchheim
> Germany
> email: sebastian.hu...@embedded-brains.de
> phone: +49-89-18 94 741 - 16
> fax:   +49-89-18 94 741 - 08
>
> Registergericht: Amtsgericht München
> Registernummer: HRB 157899
> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
> Unsere Datenschutzerklärung finden Sie hier:
> https://embedded-brains.de/datenschutzerklaerung/
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] STM32 lwIP addition

[Robin Müller]

Small correction: I changed the ethernetif.c file to be usable by all three
major APIs.

Kind Regards
Robin

On Wed, 28 Apr 2021 at 11:55, Robin Müller 
wrote:

> Should I provide the changes for the code review as a separate patch or
> should I squash them again?
>
> Using the upstream unchanged is tricky because the code was taken from the
> examples and these examples are always targeted towards a specific API.
> I changed the version to be usable by both APIs. I now applied the
> __rtems__ preprocessor defines where applicable and moved the preprocessor
> defines into a separate file.
>
> Kind Regards
> Robin
>
> On Tue, 27 Apr 2021 at 22:21, Gedare Bloom  wrote:
>
>> On Tue, Apr 27, 2021 at 2:09 PM Gedare Bloom  wrote:
>> >
>> > On Tue, Apr 27, 2021 at 11:41 AM Robin Mueller
>> >  wrote:
>> > >
>>
>> I'm not sure what happened, it looks like my email client garbled the
>> inline threaded reply. Hopefully my comments come through for you ok.
>>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Issues with rtems_waf on Windows 10 with gccdeps module

[Robin Müller]

Hi,

I think the following commit in rtems_waf breaks the waf build on Windows
10:

commit 096372fc4504730e50b51b952ce47ca603b35f01
Author: Chris Johns 
Date:   Thu Oct 10 17:43:11 2019 +1100

Use gccdeps for dependency scanning.

I get the error that RTEMS is not able to find the rtems.h file in a
certain directory when building the simple quick start application. The
error does not occur on commits before that. I tried to run waf both in the
WIndows CMD and in MinGW64, it is problematic for both.

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

Re: [PATCH] STM32 lwIP addition

[Robin Müller]

Should I provide the changes for the code review as a separate patch or
should I squash them again?

Using the upstream unchanged is tricky because the code was taken from the
examples and these examples are always targeted towards a specific API.
I changed the version to be usable by both APIs. I now applied the
__rtems__ preprocessor defines where applicable and moved the preprocessor
defines into a separate file.

Kind Regards
Robin

On Tue, 27 Apr 2021 at 22:21, Gedare Bloom  wrote:

> On Tue, Apr 27, 2021 at 2:09 PM Gedare Bloom  wrote:
> >
> > On Tue, Apr 27, 2021 at 11:41 AM Robin Mueller
> >  wrote:
> > >
>
> I'm not sure what happened, it looks like my email client garbled the
> inline threaded reply. Hopefully my comments come through for you ok.
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: tcpreplay for testing network stacks

[Chris Johns]

On 28/4/21 2:48 am, Vijay Kumar Banerjee wrote:
> I came across the tcpreplay tool and it looks like a nice tool for testing the
> network stacks. It can be used to capture network traffic and then play it 
> back,
> this will help with testing the network packets from different network stacks.
> 
> My proposal is to add the tcpreply as a host-side tool in rtems-tools and use 
> it
> with the network interface where the network application is running. The only
> issue that I see with the whole idea is that the tcpreplay is GPLv3 licensed.
> Will that be compatible for rtems-tools? The github repository says that it's
> compatible with UNIX and Windows with cygwin.
> 
> Source repository:https://github.com/appneta/tcpreplay
> 
> 
> Thoughts and suggestions are much appreciated.

It is GPLv3 so it cannot be imported as source. It can be referenced as a
command if available for the host.

I also suggest you investigate VDE with qemu. This is what I use to avoid being
root.

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

Re: tcpreplay for testing network stacks

[Christian MAUDERER]

Hello Vijay,

Am 27.04.21 um 18:48 schrieb Vijay Kumar Banerjee:

Hi,

I came across the tcpreplay tool and it looks like a nice tool for 
testing the network stacks. It can be used to capture network traffic 
and then play it back, this will help with testing the network packets 
from different network stacks.


Sounds like an interesting tool.



My proposal is to add the tcpreply as a host-side tool in rtems-tools 
and use it with the network interface where the network application is 
running. The only issue that I see with the whole idea is that the 
tcpreplay is GPLv3 licensed. Will that be compatible for rtems-tools? 
The github repository says that it's compatible with UNIX and Windows 
with cygwin.


The more difficult problem could be the missing Mac and FreeBSD support.

What would be the advantage of having tcpreply in rtems-tools? Do you 
want to use it for automated tests?


Best regards

Christian



Source repository:https://github.com/appneta/tcpreplay 



Thoughts and suggestions are much appreciated.


Best regards,
Vijay

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



--

embedded brains GmbH
Herr Christian MAUDERER
Dornierstr. 4
82178 Puchheim
Germany
email: christian.maude...@embedded-brains.de
phone: +49-89-18 94 741 - 18
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel