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

[Niteesh G. S.]

On Fri, Feb 5, 2021 at 12:22 AM Christian Mauderer 
wrote:

>
>
> On 04/02/2021 17:34, Gedare Bloom wrote:
> >
> >
> > On Thu, Feb 4, 2021 at 1:58 AM Niteesh G. S.  > > wrote:
> >
> >
> >
> > On Thu, Feb 4, 2021 at 1:21 AM Gedare Bloom  > > wrote:
> >
> >
> >
> > On Wed, Feb 3, 2021 at 2:48 AM G S Niteesh Babu
> > mailto:niteesh...@gmail.com>> wrote:
> >
> > Fixed use after free and null pointer dereference defects
> >
> > FIXES:
> > 1) CID 1472601 (NULL_RETURNS)
> > 2) CID 1472600 (USE_AFTER_FREE)
> > 3) CID 1472599 (USE_AFTER_FREE)
> > 4) CID 1472598 (USE_AFTER_FREE)
> > 5) CID 1472596 (USE_AFTER_FREE)
> > 6) CID 1472597 (ARRAY_VS_SINGLETON)
> > 7) CID 1472595 (ARRAY_VS_SINGLETON)
> > ---
> >   bsps/shared/ofw/ofw.c | 36
> > ++--
> >   1 file changed, 18 insertions(+), 18 deletions(-)
> >
> > diff --git a/bsps/shared/ofw/ofw.c b/bsps/shared/ofw/ofw.c
> > index 82924b2600..ccd57e36af 100644
> > --- a/bsps/shared/ofw/ofw.c
> > +++ b/bsps/shared/ofw/ofw.c
> > @@ -313,7 +313,7 @@ ssize_t rtems_ofw_get_prop_alloc(
> >   }
> >
> >   if (rtems_ofw_get_prop(node, propname, *buf, len) ==
> -1) {
> > -  rtems_ofw_free(buf);
> > +  rtems_ofw_free(*buf);
> > *buf = NULL;
> > return -1;
> >   }
> > @@ -344,7 +344,7 @@ ssize_t rtems_ofw_get_prop_alloc_multi(
> >   }
> >
> >   if (rtems_ofw_get_prop(node, propname, *buf, len) ==
> -1) {
> > -  rtems_ofw_free(buf);
> > +  rtems_ofw_free(*buf);
> > *buf = NULL;
> > return -1;
> >   }
> > @@ -373,7 +373,7 @@ ssize_t rtems_ofw_get_enc_prop_alloc(
> >   }
> >
> >   if (rtems_ofw_get_enc_prop(node, propname, *buf, len)
> > == -1) {
> > -  rtems_ofw_free(buf);
> > +  rtems_ofw_free(*buf);
> > *buf = NULL;
> > return -1;
> >   }
> > @@ -404,7 +404,7 @@ ssize_t
> rtems_ofw_get_enc_prop_alloc_multi(
> >   }
> >
> >   if (rtems_ofw_get_enc_prop(node, propname, *buf, len)
> > == -1) {
> > -  rtems_ofw_free(buf);
> > +  rtems_ofw_free(*buf);
> > *buf = NULL;
> > return -1;
> >   }
> >
> > The above all look fine to me.
> >
> > @@ -500,21 +500,21 @@ static phandle_t
> > rtems_ofw_get_effective_phandle(
> >   )
> >   {
> > phandle_t child;
> > -  phandle_t ref;
> > +  phandle_t ref[1];
> >
> >
> > I don't like this. I know this was suggested, but I think it is
> > a little ridiculous. This is a false positive since we know that
> > sizeof(*buf) == len. I don't know if we can make that an
> > assertion. Otherwise, we can just mark this as a false positive
> > in coverity. We know the array dereference in this case won't
> > overwrite past the bounds of ref.
> >
> > Instead of using hard-coded values of 4
> > in rtems_ofw_get_enc_prop() you might make it more explicitly
> > using sizeof(pcell_t), since that is what you mean.
> >
> > Done.
> >
> >
> > I would also agree to change the strncpy as Christian identified
> > before in rtems_ofw_get_prop().
> >
> > Is the reason to avoid strncpy that it ignores the null byte if
> > len(dst) <= len(src)?
> > If so can I do an explicit null byte append?
> > Or is there any other reason?
> >
> > The reason is that it passes void* pointers. If these are strings, you
> > should use char* type. Otherwise, memcpy is more suitable.
> >
> > It also would be generally safer to overwrite with the NIL character to
> > guarantee it is a null-terminated string, if that is expected.
>
> That was not the only reason. Let me pull the relevant lines together
> (reordered and pulled from multiple files):
>
>
> typedef uint32_t  pcell_t;
>
> rtems_ofw_get_enc_prop(
>phandle_tnode,
>const char  *prop,
>pcell_t *buf,
>size_t   len
> )
> {
>...
>rv = rtems_ofw_get_prop(node, prop, buf, len);
>...
> }
>
> rtems_ofw_get_prop(
>phandle_tnode,
>const char  *propname,
>void*buf,
>size_t   bufsize
> {
>...
>  strncpy(buf, prop, bufsize);
>...
> }
>
> Let's say I do the following call:
>
> rtems_ofw_get_enc_prop(node, "name", &foo, sizeof(fo

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

[Christian MAUDERER]

Am 05.02.21 um 09:45 schrieb Niteesh G. S.:



On Fri, Feb 5, 2021 at 12:22 AM Christian Mauderer 
mailto:cont...@c-mauderer.de>> wrote:




On 04/02/2021 17:34, Gedare Bloom wrote:
 >
 >
 > On Thu, Feb 4, 2021 at 1:58 AM Niteesh G. S.
mailto:niteesh...@gmail.com>
 > >> wrote:
 >
 >
 >
 >     On Thu, Feb 4, 2021 at 1:21 AM Gedare Bloom mailto:ged...@rtems.org>
 >     >> wrote:
 >
 >
 >
 >         On Wed, Feb 3, 2021 at 2:48 AM G S Niteesh Babu
 >         mailto:niteesh...@gmail.com>
>> wrote:
 >
 >             Fixed use after free and null pointer dereference defects
 >
 >             FIXES:
 >             1) CID 1472601 (NULL_RETURNS)
 >             2) CID 1472600 (USE_AFTER_FREE)
 >             3) CID 1472599 (USE_AFTER_FREE)
 >             4) CID 1472598 (USE_AFTER_FREE)
 >             5) CID 1472596 (USE_AFTER_FREE)
 >             6) CID 1472597 (ARRAY_VS_SINGLETON)
 >             7) CID 1472595 (ARRAY_VS_SINGLETON)
 >             ---
 >               bsps/shared/ofw/ofw.c | 36
 >             ++--
 >               1 file changed, 18 insertions(+), 18 deletions(-)
 >
 >             diff --git a/bsps/shared/ofw/ofw.c
b/bsps/shared/ofw/ofw.c
 >             index 82924b2600..ccd57e36af 100644
 >             --- a/bsps/shared/ofw/ofw.c
 >             +++ b/bsps/shared/ofw/ofw.c
 >             @@ -313,7 +313,7 @@ ssize_t rtems_ofw_get_prop_alloc(
 >                   }
 >
 >                   if (rtems_ofw_get_prop(node, propname, *buf,
len) == -1) {
 >             -      rtems_ofw_free(buf);
 >             +      rtems_ofw_free(*buf);
 >                     *buf = NULL;
 >                     return -1;
 >                   }
 >             @@ -344,7 +344,7 @@ ssize_t
rtems_ofw_get_prop_alloc_multi(
 >                   }
 >
 >                   if (rtems_ofw_get_prop(node, propname, *buf,
len) == -1) {
 >             -      rtems_ofw_free(buf);
 >             +      rtems_ofw_free(*buf);
 >                     *buf = NULL;
 >                     return -1;
 >                   }
 >             @@ -373,7 +373,7 @@ ssize_t rtems_ofw_get_enc_prop_alloc(
 >                   }
 >
 >                   if (rtems_ofw_get_enc_prop(node, propname,
*buf, len)
 >             == -1) {
 >             -      rtems_ofw_free(buf);
 >             +      rtems_ofw_free(*buf);
 >                     *buf = NULL;
 >                     return -1;
 >                   }
 >             @@ -404,7 +404,7 @@ ssize_t
rtems_ofw_get_enc_prop_alloc_multi(
 >                   }
 >
 >                   if (rtems_ofw_get_enc_prop(node, propname,
*buf, len)
 >             == -1) {
 >             -      rtems_ofw_free(buf);
 >             +      rtems_ofw_free(*buf);
 >                     *buf = NULL;
 >                     return -1;
 >                   }
 >
 >         The above all look fine to me.
 >
 >             @@ -500,21 +500,21 @@ static phandle_t
 >             rtems_ofw_get_effective_phandle(
 >               )
 >               {
 >                 phandle_t child;
 >             -  phandle_t ref;
 >             +  phandle_t ref[1];
 >
 >
 >         I don't like this. I know this was suggested, but I think
it is
 >         a little ridiculous. This is a false positive since we
know that
 >         sizeof(*buf) == len. I don't know if we can make that an
 >         assertion. Otherwise, we can just mark this as a false
positive
 >         in coverity. We know the array dereference in this case won't
 >         overwrite past the bounds of ref.
 >
 >         Instead of using hard-coded values of 4
 >         in rtems_ofw_get_enc_prop() you might make it more explicitly
 >         using sizeof(pcell_t), since that is what you mean.
 >
 >     Done.
 >
 >
 >         I would also agree to change the strncpy as Christian
identified
 >         before in rtems_ofw_get_prop().
 >
 >     Is the reason to avoid strncpy that it ignores the null byte if
 >     len(dst) <= len(src)?
 >     If so can I do an explicit null byte append?
 >     Or is there any other reason?
 >
 > The reason is that it passes void* pointers. If these are
strings, you
 > should use char* type. Otherwise, memcpy is more suitable.
 >
 > It also would be generally safer to overwrite with the NIL
character to
 > guarantee it is a null-terminated string, if that is expecte

[PATCH 1/3] score: Constify Thread_queue_First_operation

[Sebastian Huber]

Update #4230.
---
 cpukit/include/rtems/score/threadq.h | 13 +++--
 cpukit/score/src/threadqops.c| 12 ++--
 2 files changed, 13 insertions(+), 12 deletions(-)

diff --git a/cpukit/include/rtems/score/threadq.h 
b/cpukit/include/rtems/score/threadq.h
index de7ca8391b..5234019b81 100644
--- a/cpukit/include/rtems/score/threadq.h
+++ b/cpukit/include/rtems/score/threadq.h
@@ -496,16 +496,17 @@ typedef Thread_Control *( 
*Thread_queue_Surrender_operation )(
 );
 
 /**
- * @brief Thread queue first operation.
+ * @brief Gets the first thread on the queue.
  *
- * @param[in] heads The thread queue heads.
+ * @param heads are heads of the thread queue.
  *
- * @retval NULL No thread is present on the thread queue.
- * @retval first The first thread of the thread queue according to the insert
- * order.  This thread remains on the thread queue.
+ * @retval NULL No thread is enqueued on the thread queue.
+ *
+ * @return Returns the first thread on the thread queue according to the queue
+ *   order.  This thread remains on the thread queue.
  */
 typedef Thread_Control *( *Thread_queue_First_operation )(
-  Thread_queue_Heads *heads
+  const Thread_queue_Heads *heads
 );
 
 /**
diff --git a/cpukit/score/src/threadqops.c b/cpukit/score/src/threadqops.c
index 9cf63d41f6..813edf1fcd 100644
--- a/cpukit/score/src/threadqops.c
+++ b/cpukit/score/src/threadqops.c
@@ -230,16 +230,16 @@ static void _Thread_queue_FIFO_extract(
 }
 
 static Thread_Control *_Thread_queue_FIFO_first(
-  Thread_queue_Heads *heads
+  const Thread_queue_Heads *heads
 )
 {
-  Chain_Control  *fifo;
-  Chain_Node *first;
-  Scheduler_Node *scheduler_node;
+  const Chain_Control  *fifo;
+  const Chain_Node *first;
+  const Scheduler_Node *scheduler_node;
 
   fifo = &heads->Heads.Fifo;
   _Assert( !_Chain_Is_empty( fifo ) );
-  first = _Chain_First( fifo );
+  first = _Chain_Immutable_first( fifo );
   scheduler_node = SCHEDULER_NODE_OF_WAIT_PRIORITY_NODE( first );
 
   return _Scheduler_Node_get_owner( scheduler_node );
@@ -600,7 +600,7 @@ static void _Thread_queue_Priority_extract(
 }
 
 static Thread_Control *_Thread_queue_Priority_first(
-  Thread_queue_Heads *heads
+  const Thread_queue_Heads *heads
 )
 {
   Thread_queue_Priority_queue *priority_queue;
-- 
2.26.2

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

[PATCH 2/3] score: Make FIFO thread queue ops public

[Sebastian Huber]

Update #4230.
---
 cpukit/include/rtems/score/threadqops.h | 134 
 cpukit/score/src/threadqops.c   |  17 +--
 2 files changed, 143 insertions(+), 8 deletions(-)
 create mode 100644 cpukit/include/rtems/score/threadqops.h

diff --git a/cpukit/include/rtems/score/threadqops.h 
b/cpukit/include/rtems/score/threadqops.h
new file mode 100644
index 00..504383e98d
--- /dev/null
+++ b/cpukit/include/rtems/score/threadqops.h
@@ -0,0 +1,134 @@
+/* SPDX-License-Identifier: BSD-2-Clause */
+
+/**
+ * @file
+ *
+ * @ingroup RTEMSScoreThreadQueue
+ *
+ * @brief This header file provides interfaces related to thread queue
+ *   operations.
+ */
+
+/*
+ * Copyright (C) 2021 embedded brains GmbH (http://www.embedded-brains.de)
+ *
+ * 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.
+ */
+
+#ifndef _RTEMS_SCORE_THREADQOPS_H
+#define _RTEMS_SCORE_THREADQOPS_H
+
+#include 
+
+#ifdef __cplusplus
+extern "C" {
+#endif
+
+/**
+ * @addtogroup RTEMSScoreThreadQueue
+ *
+ * @{
+ */
+
+/**
+ * @brief Initializes the priority actions so that no actions are performed.
+ *
+ * @param queue is unused.
+ *
+ * @param[out] priority_actions is initialized so that no actions are
+ *   performed.
+ */
+void _Thread_queue_Do_nothing_priority_actions(
+  Thread_queue_Queue *queue,
+  Priority_Actions   *priority_actions
+);
+
+/**
+ * @brief Enqueues the thread to the FIFO thread queue.
+ *
+ * @param[in, out] queue is the thread queue.
+ *
+ * @param[in, out] the_thread is the thread to enqueue.
+ *
+ * @param[in, out] queue_context is the thread queue context.
+ */
+void _Thread_queue_FIFO_enqueue(
+  Thread_queue_Queue   *queue,
+  Thread_Control   *the_thread,
+  Thread_queue_Context *queue_context
+);
+
+/**
+ * @brief Extracts the thread from the FIFO thread queue.
+ *
+ * @param[in, out] queue is the thread queue.
+ *
+ * @param[in, out] the_thread is the thread to extract.
+ *
+ * @param[in, out] queue_context is the thread queue context.
+ */
+void _Thread_queue_FIFO_extract(
+  Thread_queue_Queue   *queue,
+  Thread_Control   *the_thread,
+  Thread_queue_Context *queue_context
+);
+
+/**
+ * @brief Surrenders the thread queue to the first thread on the FIFO thread
+ *   queue.
+ *
+ * @param[in, out] queue is the thread queue.
+ *
+ * @param[in, out] heads are heads of the thread queue.
+ *
+ * @param previous_owner is unused.
+ *
+ * @param[in, out] queue_context is the thread queue context.
+ *
+ * @return Returns the first thread on the thread queue according to the queue
+ *   order.
+ */
+Thread_Control *_Thread_queue_FIFO_surrender(
+  Thread_queue_Queue   *queue,
+  Thread_queue_Heads   *heads,
+  Thread_Control   *previous_owner,
+  Thread_queue_Context *queue_context
+);
+
+/**
+ * @brief Gets the first thread on the FIFO thread queue.
+ *
+ * @param[in, out] queue is the thread queue.
+ *
+ * @param[in, out] the_thread is the thread to extract.
+ *
+ * @param[in, out] queue_context is the thread queue context.
+ */
+Thread_Control *_Thread_queue_FIFO_first( const Thread_queue_Heads *heads );
+
+/** @} */
+
+#ifdef __cplusplus
+}
+#endif
+
+#endif /* _RTEMS_SCORE_THREADQOPS_H */
diff --git a/cpukit/score/src/threadqops.c b/cpukit/score/src/threadqops.c
index 813edf1fcd..ef20431178 100644
--- a/cpukit/score/src/threadqops.c
+++ b/cpukit/score/src/threadqops.c
@@ -10,7 +10,7 @@
  */
 
 /*
- * Copyright (c) 2015, 2016 embedded brains GmbH.  All rights reserved.
+ * Copyright (c) 2015, 2021 embedded brains GmbH.  All rights reserved.
  *
  *  embedded brains GmbH
  *  Dornierstr. 4
@@ -27,6 +27,7 @@
 #include "config.h"
 #endif
 
+#include 
 #include 
 #include 
 #include 
@@ -49,7 +50,7 @@
 Queue \
   )
 
-static void _Thread_qu

[PATCH 3/3] score: Add barrier thread queue operations

[Sebastian Huber]

This fixes a missing decrement of the number of waiting threads during a
barrier wait timeout.

Close #4230.
---
 cpukit/include/rtems/score/corebarrierimpl.h |  4 ++-
 cpukit/score/src/corebarrierrelease.c|  1 -
 cpukit/score/src/corebarrierwait.c   | 30 
 3 files changed, 33 insertions(+), 2 deletions(-)

diff --git a/cpukit/include/rtems/score/corebarrierimpl.h 
b/cpukit/include/rtems/score/corebarrierimpl.h
index c2dfea8f9b..2317d748c1 100644
--- a/cpukit/include/rtems/score/corebarrierimpl.h
+++ b/cpukit/include/rtems/score/corebarrierimpl.h
@@ -33,7 +33,9 @@ extern "C" {
  * @{
  */
 
-#define CORE_BARRIER_TQ_OPERATIONS &_Thread_queue_Operations_FIFO
+extern const Thread_queue_Operations _CORE_barrier_Thread_queue_operations;
+
+#define CORE_BARRIER_TQ_OPERATIONS &_CORE_barrier_Thread_queue_operations
 
 /**
  *  @brief Initializes the core barrier.
diff --git a/cpukit/score/src/corebarrierrelease.c 
b/cpukit/score/src/corebarrierrelease.c
index 5d510107d6..1f03b24bac 100644
--- a/cpukit/score/src/corebarrierrelease.c
+++ b/cpukit/score/src/corebarrierrelease.c
@@ -28,7 +28,6 @@ uint32_t _CORE_barrier_Do_flush(
   Thread_queue_Context  *queue_context
 )
 {
-  the_barrier->number_of_waiting_threads = 0;
   return _Thread_queue_Flush_critical(
 &the_barrier->Wait_queue.Queue,
 CORE_BARRIER_TQ_OPERATIONS,
diff --git a/cpukit/score/src/corebarrierwait.c 
b/cpukit/score/src/corebarrierwait.c
index 3da9b05953..7651e20737 100644
--- a/cpukit/score/src/corebarrierwait.c
+++ b/cpukit/score/src/corebarrierwait.c
@@ -23,6 +23,36 @@
 #include 
 #include 
 #include 
+#include 
+
+static void _CORE_barrier_Thread_queue_extract(
+  Thread_queue_Queue   *queue,
+  Thread_Control   *the_thread,
+  Thread_queue_Context *queue_context
+)
+{
+  CORE_barrier_Control *the_barrier;
+
+  the_barrier = RTEMS_CONTAINER_OF(
+queue,
+CORE_barrier_Control,
+Wait_queue.Queue
+  );
+  --the_barrier->number_of_waiting_threads;
+  _Thread_queue_FIFO_extract(
+&the_barrier->Wait_queue.Queue,
+the_thread,
+queue_context
+  );
+}
+
+const Thread_queue_Operations _CORE_barrier_Thread_queue_operations = {
+  .priority_actions = _Thread_queue_Do_nothing_priority_actions,
+  .enqueue = _Thread_queue_FIFO_enqueue,
+  .extract = _CORE_barrier_Thread_queue_extract,
+  .surrender = _Thread_queue_FIFO_surrender,
+  .first = _Thread_queue_FIFO_first
+};
 
 Status_Control _CORE_barrier_Seize(
   CORE_barrier_Control *the_barrier,
-- 
2.26.2

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

Re: [PATCH v2] Test suite for FTW.H methods

[Joel Sherrill]

Does the waf support actually build psxftw01.tar or is that a constant
magic file?
I might have missed it but I didn't see any logic to create it.

Other than that, I don't have any issues.

--joel

On Wed, Feb 3, 2021 at 3:34 PM Eshan Dhawan  wrote:

> From: Eshan dhawan 
>
> Signed-off-by: Eshan Dhawan 
> ---
>  spec/build/testsuites/psxtests/grp.yml  |   2 +
>  spec/build/testsuites/psxtests/psxftw01.yml |  34 
>  testsuites/psxtests/Makefile.am |  26 +++
>  testsuites/psxtests/configure.ac|   1 +
>  testsuites/psxtests/psxftw01/init.c | 204 
>  testsuites/psxtests/psxftw01/psxftw01.doc   |  18 ++
>  testsuites/psxtests/psxftw01/psxftw01.scn   |  10 +
>  testsuites/psxtests/psxftw01/psxftw01.tar   | Bin 0 -> 3584 bytes
>  8 files changed, 295 insertions(+)
>  create mode 100644 spec/build/testsuites/psxtests/psxftw01.yml
>  create mode 100644 testsuites/psxtests/psxftw01/init.c
>  create mode 100644 testsuites/psxtests/psxftw01/psxftw01.doc
>  create mode 100644 testsuites/psxtests/psxftw01/psxftw01.scn
>  create mode 100644 testsuites/psxtests/psxftw01/psxftw01.tar
>
> diff --git a/spec/build/testsuites/psxtests/grp.yml
> b/spec/build/testsuites/psxtests/grp.yml
> index 47dedac275..fb7ce465ae 100644
> --- a/spec/build/testsuites/psxtests/grp.yml
> +++ b/spec/build/testsuites/psxtests/grp.yml
> @@ -109,6 +109,8 @@ links:
>uid: psxfile02
>  - role: build-dependency
>uid: psxfilelock01
> +- role: build-dependency
> +  uid: psxftw01
>  - role: build-dependency
>uid: psxgetattrnp01
>  - role: build-dependency
> diff --git a/spec/build/testsuites/psxtests/psxftw01.yml
> b/spec/build/testsuites/psxtests/psxftw01.yml
> new file mode 100644
> index 00..c8b2a4fb59
> --- /dev/null
> +++ b/spec/build/testsuites/psxtests/psxftw01.yml
> @@ -0,0 +1,34 @@
> +SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
> +build-type: script
> +cflags: []
> +copyrights:
> +- Copyright (C) 2020 Eshan Dhawan
> +cppflags: []
> +do-build: |
> +  path = "testsuites/psxtests/psxftw01/"
> +  tar = path + "psxftw01.tar"
> +  tar_gz = self.gzip(bld, tar)
> +  tar_xz = self.xz(bld, tar)
> +  tar_c, tar_h = self.bin2c(bld, tar)
> +  tar_gz_c, tar_gz_h = self.bin2c(bld, tar_gz)
> +  tar_xz_c, tar_xz_h = self.bin2c(bld, tar_xz)
> +  objs = []
> +  objs.append(self.cc(bld, bic, tar_c))
> +  objs.append(self.cc(bld, bic, tar_gz_c))
> +  objs.append(self.cc(bld, bic, tar_xz_c))
> +  objs.append(self.cc(bld, bic, path + "init.c", deps=[tar_h, tar_gz_h,
> tar_xz_h], cppflags=bld.env.TEST_psxftw01_CPPFLAGS))
> +  objs.append(self.cc(bld, bic,
> "testsuites/psxtests/psxfile01/test_cat.c", target=path + "test_cat.o"))
> +  self.link_cc(bld, bic, objs, "testsuites/psxtests/psxftw01.exe")
> +do-configure: null
> +enabled-by: true
> +includes:
> +- testsuites/psxtests/psxftw01
> +ldflags: []
> +links: []
> +prepare-build: null
> +prepare-configure: null
> +stlib: []
> +type: build
> +use-after:
> +- z
> +use-before: []
> diff --git a/testsuites/psxtests/Makefile.am
> b/testsuites/psxtests/Makefile.am
> index d89bcd8801..a35f00b665 100755
> --- a/testsuites/psxtests/Makefile.am
> +++ b/testsuites/psxtests/Makefile.am
> @@ -453,6 +453,32 @@ psxfilelock01_CPPFLAGS = $(AM_CPPFLAGS)
> $(TEST_FLAGS_psxfilelock01) \
> $(support_includes)
>  endif
>
> +if TEST_psxftw01
> +psx_tests += psxftw01
> +psx_screens += psxftw01/psxftw01.scn
> +psx_docs += psxftw01/psxftw01.doc
> +psxftw01_SOURCES = psxftw01/init.c psxfile01/test_cat.c \
> +   psxftw01-tar.c psxftw01-tar.h psxftw01-tar-gz.c psxftw01-tar-gz.h
> +
> +psxftw01_CPPFLAGS = $(AM_CPPFLAGS) $(TEST_FLAGS_psxftw01) \
> +   $(support_includes) $(test_includes) -I$(top_srcdir)/include
> +psxftw01_LDADD = $(RTEMS_ROOT)cpukit/librtemscpu.a
> $(RTEMS_ROOT)cpukit/libz.a $(LDADD)
> +psxftw01-tar.c: psxftw01/psxftw01.tar
> +   $(AM_V_GEN)$(BIN2C) -C $< $@
> +psxftw01-tar.h: psxftw01/psxftw01.tar
> +   $(AM_V_GEN)$(BIN2C) -H $< $@
> +psxftw01-tar.o: psxftw01-tar.c psxftw01-tar.h
> +psxftw01.tar.gz: psxftw01/psxftw01.tar
> +   $(AM_V_GEN)$(GZIP) < $< > $@
> +psxftw01-tar-gz.c: psxftw01.tar.gz
> +   $(AM_V_GEN)$(BIN2C) -C $< $@
> +psxftw01-tar-gz.h: psxftw01.tar.gz
> +   $(AM_V_GEN)$(BIN2C) -H $< $@
> +CLEANFILES += psxftw01.tar psxftw01-tar.c psxftw01-tar.h \
> +   psxftw01.tar.gz psxftw01-tar-gz.c psxftw01-tar-gz.h
> +psxftw01/init.c: psxftw01-tar.h psxftw01-tar-gz.h $(TAR01_XZ_H)
> +endif
> +
>  if TEST_psxgetattrnp01
>  psx_tests += psxgetattrnp01
>  psx_screens += psxgetattrnp01/psxgetattrnp01.scn
> diff --git a/testsuites/psxtests/configure.ac b/testsuites/psxtests/
> configure.ac
> index 139787cccb..3f95010cd3 100644
> --- a/testsuites/psxtests/configure.ac
> +++ b/testsuites/psxtests/configure.ac
> @@ -90,6 +90,7 @@ RTEMS_TEST_CHECK([psxfenv01])
>  RTEMS_TEST_CHECK([psxfile01])
>  RTEMS_TEST_CHECK([psxfile02])
>  RTEMS_TEST_CHECK([psxfilelock01])
> +RTEMS_TEST_CHECK([psxftw01])
>  RTEMS_TEST_CHE

Re: [PATCH v5] Confstr support for RTEMS

[Joel Sherrill]

On Wed, Feb 3, 2021 at 3:46 PM Eshan Dhawan  wrote:

> From: Eshan dhawan 
>
> Signed-off-by: Eshan Dhawan 
> ---
>  cpukit/Makefile.am|   1 +
>  cpukit/posix/src/confstr.c| 103 +
>  spec/build/cpukit/librtemscpu.yml |   1 +
>  spec/build/testsuites/psxtests/grp.yml|   2 +
>  spec/build/testsuites/psxtests/psxconfstr.yml |  20 +++
>  testsuites/psxtests/Makefile.am   |   9 ++
>  testsuites/psxtests/configure.ac  |   1 +
>  testsuites/psxtests/psxconfstr/init.c | 143 ++
>  testsuites/psxtests/psxconfstr/psxconfstr.doc |  17 +++
>  testsuites/psxtests/psxconfstr/psxconfstr.scn |   4 +
>  10 files changed, 301 insertions(+)
>  create mode 100644 cpukit/posix/src/confstr.c
>  create mode 100644 spec/build/testsuites/psxtests/psxconfstr.yml
>  create mode 100644 testsuites/psxtests/psxconfstr/init.c
>  create mode 100644 testsuites/psxtests/psxconfstr/psxconfstr.doc
>  create mode 100644 testsuites/psxtests/psxconfstr/psxconfstr.scn
>
> diff --git a/cpukit/Makefile.am b/cpukit/Makefile.am
> index 565aa66ce1..469754ab84 100644
> --- a/cpukit/Makefile.am
> +++ b/cpukit/Makefile.am
> @@ -511,6 +511,7 @@ librtemscpu_a_SOURCES += posix/src/condsignalsupp.c
>  librtemscpu_a_SOURCES += posix/src/condtimedwait.c
>  librtemscpu_a_SOURCES += posix/src/condwait.c
>  librtemscpu_a_SOURCES += posix/src/condwaitsupp.c
> +librtemscpu_a_SOURCES += posix/src/confstr.c
>  librtemscpu_a_SOURCES += posix/src/_execve.c
>  librtemscpu_a_SOURCES += posix/src/fork.c
>  librtemscpu_a_SOURCES += posix/src/key.c
> diff --git a/cpukit/posix/src/confstr.c b/cpukit/posix/src/confstr.c
> new file mode 100644
> index 00..337c4f471d
> --- /dev/null
> +++ b/cpukit/posix/src/confstr.c
> @@ -0,0 +1,103 @@
> +/*-
> + * SPDX-License-Identifier: BSD-3-Clause
> + *
> + * Copyright (c) 1993
> + * The Regents of the University of California.  All rights reserved.
> + *
> + * 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.
> + * 3. Neither the name of the University nor the names of its contributors
> + *may be used to endorse or promote products derived from this
> software
> + *without specific prior written permission.
> + *
> + * THIS SOFTWARE IS PROVIDED BY THE REGENTS 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 REGENTS OR CONTRIBUTORS BE
> LIABLE
> + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
> CONSEQUENTIAL
> + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
> + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
> + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,
> STRICT
> + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY
> WAY
> + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
> + * SUCH DAMAGE.
> + */
> +
> +#include 
> +/* Reduced to make sense in RTEMS */



> +__SCCSID("@(#)confstr.c8.1 (Berkeley) 6/4/93");
> +__FBSDID("$FreeBSD$");
>

I don't recall if we comment these out or have macros which turn them to
nothing.

> +
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +#include 
>

You may not need limits.h. Check.


> +
> +/* Many programming environment flags have same values
> +* this block is added to raise error if the flags value change
> +*/
> +
> +#if (_CS_V6_ENV != _CS_V7_ENV)
> +#error "_CS_V6_XXX and _CS_V7_XXX flag values not equal"
> +#endif
>

This was intended to be representative of a pattern of adding a check to
ensure every V6 and V7 constant with the same meaning and return value
actually had the same value. This should be repeated for each of these:

case _CS_POSIX_V6_ILP32_OFF32_CFLAGS:
case _CS_POSIX_V6_ILP32_OFF32_LDFLAGS:
case _CS_POSIX_V6_ILP32_OFF32_LIBS:
case _CS_POSIX_V6_LPBIG_OFFBIG_CFLAGS:
case _CS_POSIX_V6_LPBIG_OFFBIG_LDFLAGS:
case _CS_POSIX_V6_LPBIG_OFFBIG_LIBS:
case _CS_POSIX_V6_ILP32_OFFBIG_CFLAGS:
case _CS_POSIX_V6_ILP32_OFFBIG_LDFLAGS:
case _CS_POSIX_V6_ILP32_OFFBIG_LIBS:
case _CS_POSIX_V6_LP64_OFF64_CFLAGS:
case _CS_POSIX_V6_LP64_OFF64_LDFLAGS:
case _CS_POSIX_V6_LP64_OFF64_LIBS:

And the #error should use the right name not XXX.




> +
> +size_t
> +confstr(int name, char *buf, size_t len)
> +{
> + 

[PATCH 1/2] libtest: Add T_get_thread_timer_state()

[Sebastian Huber]

---
 cpukit/include/rtems/test.h| 11 ++-
 cpukit/libtest/t-test-rtems-objs.c | 29 +
 2 files changed, 39 insertions(+), 1 deletion(-)

diff --git a/cpukit/include/rtems/test.h b/cpukit/include/rtems/test.h
index f96a5a6892..b42bf5f058 100644
--- a/cpukit/include/rtems/test.h
+++ b/cpukit/include/rtems/test.h
@@ -1,7 +1,7 @@
 /*
  * SPDX-License-Identifier: BSD-2-Clause
  *
- * Copyright (C) 2017, 2020 embedded brains GmbH
+ * Copyright (C) 2017, 2021 embedded brains GmbH
  *
  * Redistribution and use in source and binary forms, with or without
  * modification, are permitted provided that the following conditions
@@ -2503,6 +2503,15 @@ void T_check_posix_shms(T_event, const char *);
 void T_check_posix_threads(T_event, const char *);
 
 void T_check_posix_timers(T_event, const char *);
+
+typedef enum {
+   T_THREAD_TIMER_NO_THREAD,
+   T_THREAD_TIMER_SCHEDULED,
+   T_THREAD_TIMER_PENDING,
+   T_THREAD_TIMER_INACTIVE
+} T_thread_timer_state;
+
+T_thread_timer_state T_get_thread_timer_state(uint32_t);
 #endif /* __rtems__ */
 
 /**
diff --git a/cpukit/libtest/t-test-rtems-objs.c 
b/cpukit/libtest/t-test-rtems-objs.c
index ed7222e98e..a0f2ba3b73 100644
--- a/cpukit/libtest/t-test-rtems-objs.c
+++ b/cpukit/libtest/t-test-rtems-objs.c
@@ -43,6 +43,35 @@
 
 #include 
 
+T_thread_timer_state
+T_get_thread_timer_state(uint32_t id)
+{
+   Thread_Control *the_thread;
+   ISR_lock_Context lock_context;
+   T_thread_timer_state state;
+
+   the_thread = _Thread_Get(id, &lock_context);
+   if ( the_thread == NULL ) {
+   return T_THREAD_TIMER_NO_THREAD;
+   }
+
+   switch (_Watchdog_Get_state(&the_thread->Timer.Watchdog)) {
+   case WATCHDOG_SCHEDULED_BLACK:
+   case WATCHDOG_SCHEDULED_RED:
+   state = T_THREAD_TIMER_SCHEDULED;
+   break;
+   case WATCHDOG_PENDING:
+   state = T_THREAD_TIMER_PENDING;
+   break;
+   default:
+   state = T_THREAD_TIMER_INACTIVE;
+   break;
+   }
+
+   _ISR_lock_ISR_enable(&lock_context);
+   return state;
+}
+
 Objects_Maximum
 T_objects_count(Objects_APIs api, uint16_t cls)
 {
-- 
2.26.2

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

[PATCH 2/2] validation: Tests for barrier manager

[Sebastian Huber]

---
 .../testsuites/validation/validation-0.yml|   4 +
 testsuites/validation/tc-barrier-create.c | 745 ++
 testsuites/validation/tc-barrier-delete.c | 451 +++
 testsuites/validation/tc-barrier-release.c| 588 ++
 testsuites/validation/tc-barrier-wait.c   | 687 
 5 files changed, 2475 insertions(+)
 create mode 100644 testsuites/validation/tc-barrier-create.c
 create mode 100644 testsuites/validation/tc-barrier-delete.c
 create mode 100644 testsuites/validation/tc-barrier-release.c
 create mode 100644 testsuites/validation/tc-barrier-wait.c

diff --git a/spec/build/testsuites/validation/validation-0.yml 
b/spec/build/testsuites/validation/validation-0.yml
index 7fc9519cd4..8d7bf8d533 100644
--- a/spec/build/testsuites/validation/validation-0.yml
+++ b/spec/build/testsuites/validation/validation-0.yml
@@ -12,7 +12,11 @@ ldflags: []
 links: []
 source:
 - testsuites/validation/tc-attr.c
+- testsuites/validation/tc-barrier-create.c
+- testsuites/validation/tc-barrier-delete.c
 - testsuites/validation/tc-barrier-ident.c
+- testsuites/validation/tc-barrier-release.c
+- testsuites/validation/tc-barrier-wait.c
 - testsuites/validation/tc-basedefs-pendant.c
 - testsuites/validation/tc-basedefs.c
 - testsuites/validation/tc-events.c
diff --git a/testsuites/validation/tc-barrier-create.c 
b/testsuites/validation/tc-barrier-create.c
new file mode 100644
index 00..7f84b1d05b
--- /dev/null
+++ b/testsuites/validation/tc-barrier-create.c
@@ -0,0 +1,745 @@
+/* SPDX-License-Identifier: BSD-2-Clause */
+
+/**
+ * @file
+ *
+ * @ingroup RTEMSTestCaseRtemsBarrierReqCreate
+ */
+
+/*
+ * Copyright (C) 2021 embedded brains GmbH (http://www.embedded-brains.de)
+ *
+ * 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.
+ */
+
+/*
+ * This file 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 or patch to an RTEMS mailing list
+ * or raise a bug report:
+ *
+ * https://www.rtems.org/bugs.html
+ *
+ * For information on updating and regenerating please refer to the How-To
+ * section in the Software Requirements Engineering chapter of the
+ * RTEMS Software Engineering manual.  The manual is provided as a part of
+ * a release.  For development sources please refer to the online
+ * documentation at:
+ *
+ * https://docs.rtems.org
+ */
+
+#ifdef HAVE_CONFIG_H
+#include "config.h"
+#endif
+
+#include 
+#include 
+
+#include 
+
+/**
+ * @defgroup RTEMSTestCaseRtemsBarrierReqCreate spec:/rtems/barrier/req/create
+ *
+ * @ingroup RTEMSTestSuiteTestsuitesValidation0
+ *
+ * @{
+ */
+
+typedef enum {
+  RtemsBarrierReqCreate_Pre_Name_Valid,
+  RtemsBarrierReqCreate_Pre_Name_Invalid,
+  RtemsBarrierReqCreate_Pre_Name_NA
+} RtemsBarrierReqCreate_Pre_Name;
+
+typedef enum {
+  RtemsBarrierReqCreate_Pre_Class_Default,
+  RtemsBarrierReqCreate_Pre_Class_Manual,
+  RtemsBarrierReqCreate_Pre_Class_Auto,
+  RtemsBarrierReqCreate_Pre_Class_NA
+} RtemsBarrierReqCreate_Pre_Class;
+
+typedef enum {
+  RtemsBarrierReqCreate_Pre_MaxWait_Zero,
+  RtemsBarrierReqCreate_Pre_MaxWait_Positive,
+  RtemsBarrierReqCreate_Pre_MaxWait_NA
+} RtemsBarrierReqCreate_Pre_MaxWait;
+
+typedef enum {
+  RtemsBarrierReqCreate_Pre_Id_Valid,
+  RtemsBarrierReqCreate_Pre_Id_Null,
+  RtemsBarrierReqCreate_Pre_Id_NA
+} RtemsBarrierReqCreate_Pre_Id;
+
+typedef enum {
+  RtemsBarrierReqCreate_Post_Status_Ok,
+  RtemsBarrierReqCreate_Post_Status_InvName,
+  RtemsBarrierReqCreate_Post_Status_InvAddr,
+  RtemsBarrierReqCreate_Post_Status_InvNum,
+  RtemsBarrierReqCreate_Post_Status_TooMany,
+  RtemsBarrierReqCreate_Post_Status_NA
+} RtemsBarrierReqCr

Zynq Qemu with rtems-tester?

[Joel Sherrill]

Hi

Has anyone tried this lately on the master? My test script ended up with
100% failures.

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

Re: [PATCH v2] Test suite for FTW.H methods

[Eshan Dhawan]

On Fri, Feb 5, 2021 at 7:31 PM Joel Sherrill  wrote:

> Does the waf support actually build psxftw01.tar or is that a constant
> magic file?
> I might have missed it but I didn't see any logic to create it.
>
Its the constant magic file modified from libtests/tar01

>
> Other than that, I don't have any issues.
>
> --joel
>
> On Wed, Feb 3, 2021 at 3:34 PM Eshan Dhawan 
> wrote:
>
>> From: Eshan dhawan 
>>
>> Signed-off-by: Eshan Dhawan 
>> ---
>>  spec/build/testsuites/psxtests/grp.yml  |   2 +
>>  spec/build/testsuites/psxtests/psxftw01.yml |  34 
>>  testsuites/psxtests/Makefile.am |  26 +++
>>  testsuites/psxtests/configure.ac|   1 +
>>  testsuites/psxtests/psxftw01/init.c | 204 
>>  testsuites/psxtests/psxftw01/psxftw01.doc   |  18 ++
>>  testsuites/psxtests/psxftw01/psxftw01.scn   |  10 +
>>  testsuites/psxtests/psxftw01/psxftw01.tar   | Bin 0 -> 3584 bytes
>>  8 files changed, 295 insertions(+)
>>  create mode 100644 spec/build/testsuites/psxtests/psxftw01.yml
>>  create mode 100644 testsuites/psxtests/psxftw01/init.c
>>  create mode 100644 testsuites/psxtests/psxftw01/psxftw01.doc
>>  create mode 100644 testsuites/psxtests/psxftw01/psxftw01.scn
>>  create mode 100644 testsuites/psxtests/psxftw01/psxftw01.tar
>>
>> diff --git a/spec/build/testsuites/psxtests/grp.yml
>> b/spec/build/testsuites/psxtests/grp.yml
>> index 47dedac275..fb7ce465ae 100644
>> --- a/spec/build/testsuites/psxtests/grp.yml
>> +++ b/spec/build/testsuites/psxtests/grp.yml
>> @@ -109,6 +109,8 @@ links:
>>uid: psxfile02
>>  - role: build-dependency
>>uid: psxfilelock01
>> +- role: build-dependency
>> +  uid: psxftw01
>>  - role: build-dependency
>>uid: psxgetattrnp01
>>  - role: build-dependency
>> diff --git a/spec/build/testsuites/psxtests/psxftw01.yml
>> b/spec/build/testsuites/psxtests/psxftw01.yml
>> new file mode 100644
>> index 00..c8b2a4fb59
>> --- /dev/null
>> +++ b/spec/build/testsuites/psxtests/psxftw01.yml
>> @@ -0,0 +1,34 @@
>> +SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
>> +build-type: script
>> +cflags: []
>> +copyrights:
>> +- Copyright (C) 2020 Eshan Dhawan
>> +cppflags: []
>> +do-build: |
>> +  path = "testsuites/psxtests/psxftw01/"
>> +  tar = path + "psxftw01.tar"
>> +  tar_gz = self.gzip(bld, tar)
>> +  tar_xz = self.xz(bld, tar)
>> +  tar_c, tar_h = self.bin2c(bld, tar)
>> +  tar_gz_c, tar_gz_h = self.bin2c(bld, tar_gz)
>> +  tar_xz_c, tar_xz_h = self.bin2c(bld, tar_xz)
>> +  objs = []
>> +  objs.append(self.cc(bld, bic, tar_c))
>> +  objs.append(self.cc(bld, bic, tar_gz_c))
>> +  objs.append(self.cc(bld, bic, tar_xz_c))
>> +  objs.append(self.cc(bld, bic, path + "init.c", deps=[tar_h, tar_gz_h,
>> tar_xz_h], cppflags=bld.env.TEST_psxftw01_CPPFLAGS))
>> +  objs.append(self.cc(bld, bic,
>> "testsuites/psxtests/psxfile01/test_cat.c", target=path + "test_cat.o"))
>> +  self.link_cc(bld, bic, objs, "testsuites/psxtests/psxftw01.exe")
>> +do-configure: null
>> +enabled-by: true
>> +includes:
>> +- testsuites/psxtests/psxftw01
>> +ldflags: []
>> +links: []
>> +prepare-build: null
>> +prepare-configure: null
>> +stlib: []
>> +type: build
>> +use-after:
>> +- z
>> +use-before: []
>> diff --git a/testsuites/psxtests/Makefile.am
>> b/testsuites/psxtests/Makefile.am
>> index d89bcd8801..a35f00b665 100755
>> --- a/testsuites/psxtests/Makefile.am
>> +++ b/testsuites/psxtests/Makefile.am
>> @@ -453,6 +453,32 @@ psxfilelock01_CPPFLAGS = $(AM_CPPFLAGS)
>> $(TEST_FLAGS_psxfilelock01) \
>> $(support_includes)
>>  endif
>>
>> +if TEST_psxftw01
>> +psx_tests += psxftw01
>> +psx_screens += psxftw01/psxftw01.scn
>> +psx_docs += psxftw01/psxftw01.doc
>> +psxftw01_SOURCES = psxftw01/init.c psxfile01/test_cat.c \
>> +   psxftw01-tar.c psxftw01-tar.h psxftw01-tar-gz.c psxftw01-tar-gz.h
>> +
>> +psxftw01_CPPFLAGS = $(AM_CPPFLAGS) $(TEST_FLAGS_psxftw01) \
>> +   $(support_includes) $(test_includes) -I$(top_srcdir)/include
>> +psxftw01_LDADD = $(RTEMS_ROOT)cpukit/librtemscpu.a
>> $(RTEMS_ROOT)cpukit/libz.a $(LDADD)
>> +psxftw01-tar.c: psxftw01/psxftw01.tar
>> +   $(AM_V_GEN)$(BIN2C) -C $< $@
>> +psxftw01-tar.h: psxftw01/psxftw01.tar
>> +   $(AM_V_GEN)$(BIN2C) -H $< $@
>> +psxftw01-tar.o: psxftw01-tar.c psxftw01-tar.h
>> +psxftw01.tar.gz: psxftw01/psxftw01.tar
>> +   $(AM_V_GEN)$(GZIP) < $< > $@
>> +psxftw01-tar-gz.c: psxftw01.tar.gz
>> +   $(AM_V_GEN)$(BIN2C) -C $< $@
>> +psxftw01-tar-gz.h: psxftw01.tar.gz
>> +   $(AM_V_GEN)$(BIN2C) -H $< $@
>> +CLEANFILES += psxftw01.tar psxftw01-tar.c psxftw01-tar.h \
>> +   psxftw01.tar.gz psxftw01-tar-gz.c psxftw01-tar-gz.h
>> +psxftw01/init.c: psxftw01-tar.h psxftw01-tar-gz.h $(TAR01_XZ_H)
>> +endif
>> +
>>  if TEST_psxgetattrnp01
>>  psx_tests += psxgetattrnp01
>>  psx_screens += psxgetattrnp01/psxgetattrnp01.scn
>> diff --git a/testsuites/psxtests/configure.ac b/testsuites/psxtests/
>> configure.ac
>> index 139787cccb..3f95010cd3 100644
>> --- a/testsuites/psxtests/conf

Re: [PATCH v5] Confstr support for RTEMS

[Eshan Dhawan]

On Fri, Feb 5, 2021 at 7:41 PM Joel Sherrill  wrote:

>
>
> On Wed, Feb 3, 2021 at 3:46 PM Eshan Dhawan 
> wrote:
>
>> From: Eshan dhawan 
>>
>> Signed-off-by: Eshan Dhawan 
>> ---
>>  cpukit/Makefile.am|   1 +
>>  cpukit/posix/src/confstr.c| 103 +
>>  spec/build/cpukit/librtemscpu.yml |   1 +
>>  spec/build/testsuites/psxtests/grp.yml|   2 +
>>  spec/build/testsuites/psxtests/psxconfstr.yml |  20 +++
>>  testsuites/psxtests/Makefile.am   |   9 ++
>>  testsuites/psxtests/configure.ac  |   1 +
>>  testsuites/psxtests/psxconfstr/init.c | 143 ++
>>  testsuites/psxtests/psxconfstr/psxconfstr.doc |  17 +++
>>  testsuites/psxtests/psxconfstr/psxconfstr.scn |   4 +
>>  10 files changed, 301 insertions(+)
>>  create mode 100644 cpukit/posix/src/confstr.c
>>  create mode 100644 spec/build/testsuites/psxtests/psxconfstr.yml
>>  create mode 100644 testsuites/psxtests/psxconfstr/init.c
>>  create mode 100644 testsuites/psxtests/psxconfstr/psxconfstr.doc
>>  create mode 100644 testsuites/psxtests/psxconfstr/psxconfstr.scn
>>
>> diff --git a/cpukit/Makefile.am b/cpukit/Makefile.am
>> index 565aa66ce1..469754ab84 100644
>> --- a/cpukit/Makefile.am
>> +++ b/cpukit/Makefile.am
>> @@ -511,6 +511,7 @@ librtemscpu_a_SOURCES += posix/src/condsignalsupp.c
>>  librtemscpu_a_SOURCES += posix/src/condtimedwait.c
>>  librtemscpu_a_SOURCES += posix/src/condwait.c
>>  librtemscpu_a_SOURCES += posix/src/condwaitsupp.c
>> +librtemscpu_a_SOURCES += posix/src/confstr.c
>>  librtemscpu_a_SOURCES += posix/src/_execve.c
>>  librtemscpu_a_SOURCES += posix/src/fork.c
>>  librtemscpu_a_SOURCES += posix/src/key.c
>> diff --git a/cpukit/posix/src/confstr.c b/cpukit/posix/src/confstr.c
>> new file mode 100644
>> index 00..337c4f471d
>> --- /dev/null
>> +++ b/cpukit/posix/src/confstr.c
>> @@ -0,0 +1,103 @@
>> +/*-
>> + * SPDX-License-Identifier: BSD-3-Clause
>> + *
>> + * Copyright (c) 1993
>> + * The Regents of the University of California.  All rights reserved.
>> + *
>> + * 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.
>> + * 3. Neither the name of the University nor the names of its
>> contributors
>> + *may be used to endorse or promote products derived from this
>> software
>> + *without specific prior written permission.
>> + *
>> + * THIS SOFTWARE IS PROVIDED BY THE REGENTS 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 REGENTS OR CONTRIBUTORS BE
>> LIABLE
>> + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
>> CONSEQUENTIAL
>> + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE
>> GOODS
>> + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
>> + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,
>> STRICT
>> + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY
>> WAY
>> + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
>> + * SUCH DAMAGE.
>> + */
>> +
>> +#include 
>> +/* Reduced to make sense in RTEMS */
>
>
>
>> +__SCCSID("@(#)confstr.c8.1 (Berkeley) 6/4/93");
>> +__FBSDID("$FreeBSD$");
>>
>
> I don't recall if we comment these out or have macros which turn them to
> nothing.
>
>> +
>> +#include 
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>>
>
> You may not need limits.h. Check.
>
>
>> +
>> +/* Many programming environment flags have same values
>> +* this block is added to raise error if the flags value change
>> +*/
>> +
>> +#if (_CS_V6_ENV != _CS_V7_ENV)
>> +#error "_CS_V6_XXX and _CS_V7_XXX flag values not equal"
>> +#endif
>>
>
> This was intended to be representative of a pattern of adding a check to
> ensure every V6 and V7 constant with the same meaning and return value
> actually had the same value. This should be repeated for each of these:
>
> case _CS_POSIX_V6_ILP32_OFF32_CFLAGS:
> case _CS_POSIX_V6_ILP32_OFF32_LDFLAGS:
> case _CS_POSIX_V6_ILP32_OFF32_LIBS:
> case _CS_POSIX_V6_LPBIG_OFFBIG_CFLAGS:
> case _CS_POSIX_V6_LPBIG_OFFBIG_LDFLAGS:
> case _CS_POSIX_V6_LPBIG_OFFBIG_LIBS:
> case _CS_POSIX_V6_ILP32_OFFBIG_CFLAGS:
> case _CS_POSIX_V6_ILP32_OFFBIG_LDFLAGS:
> case _CS_POSIX_V6_ILP32_OFFBIG_LIBS:
> case _CS_POSIX_V6_LP64_OF

Re: [PATCH 3/3] score: Add barrier thread queue operations

[Gedare Bloom]

On Fri, Feb 5, 2021 at 6:37 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> This fixes a missing decrement of the number of waiting threads during a
> barrier wait timeout.
>
> Close #4230.
>
Is this bug a problem that should be fixed on any open branch(es)?

Otherwise, the 3 patches look good.

---
>  cpukit/include/rtems/score/corebarrierimpl.h |  4 ++-
>  cpukit/score/src/corebarrierrelease.c|  1 -
>  cpukit/score/src/corebarrierwait.c   | 30 
>  3 files changed, 33 insertions(+), 2 deletions(-)
>
> diff --git a/cpukit/include/rtems/score/corebarrierimpl.h
> b/cpukit/include/rtems/score/corebarrierimpl.h
> index c2dfea8f9b..2317d748c1 100644
> --- a/cpukit/include/rtems/score/corebarrierimpl.h
> +++ b/cpukit/include/rtems/score/corebarrierimpl.h
> @@ -33,7 +33,9 @@ extern "C" {
>   * @{
>   */
>
> -#define CORE_BARRIER_TQ_OPERATIONS &_Thread_queue_Operations_FIFO
> +extern const Thread_queue_Operations
> _CORE_barrier_Thread_queue_operations;
> +
> +#define CORE_BARRIER_TQ_OPERATIONS &_CORE_barrier_Thread_queue_operations
>
>  /**
>   *  @brief Initializes the core barrier.
> diff --git a/cpukit/score/src/corebarrierrelease.c
> b/cpukit/score/src/corebarrierrelease.c
> index 5d510107d6..1f03b24bac 100644
> --- a/cpukit/score/src/corebarrierrelease.c
> +++ b/cpukit/score/src/corebarrierrelease.c
> @@ -28,7 +28,6 @@ uint32_t _CORE_barrier_Do_flush(
>Thread_queue_Context  *queue_context
>  )
>  {
> -  the_barrier->number_of_waiting_threads = 0;
>return _Thread_queue_Flush_critical(
>  &the_barrier->Wait_queue.Queue,
>  CORE_BARRIER_TQ_OPERATIONS,
> diff --git a/cpukit/score/src/corebarrierwait.c
> b/cpukit/score/src/corebarrierwait.c
> index 3da9b05953..7651e20737 100644
> --- a/cpukit/score/src/corebarrierwait.c
> +++ b/cpukit/score/src/corebarrierwait.c
> @@ -23,6 +23,36 @@
>  #include 
>  #include 
>  #include 
> +#include 
> +
> +static void _CORE_barrier_Thread_queue_extract(
> +  Thread_queue_Queue   *queue,
> +  Thread_Control   *the_thread,
> +  Thread_queue_Context *queue_context
> +)
> +{
> +  CORE_barrier_Control *the_barrier;
> +
> +  the_barrier = RTEMS_CONTAINER_OF(
> +queue,
> +CORE_barrier_Control,
> +Wait_queue.Queue
> +  );
> +  --the_barrier->number_of_waiting_threads;
> +  _Thread_queue_FIFO_extract(
> +&the_barrier->Wait_queue.Queue,
> +the_thread,
> +queue_context
> +  );
> +}
> +
> +const Thread_queue_Operations _CORE_barrier_Thread_queue_operations = {
> +  .priority_actions = _Thread_queue_Do_nothing_priority_actions,
> +  .enqueue = _Thread_queue_FIFO_enqueue,
> +  .extract = _CORE_barrier_Thread_queue_extract,
> +  .surrender = _Thread_queue_FIFO_surrender,
> +  .first = _Thread_queue_FIFO_first
> +};
>
>  Status_Control _CORE_barrier_Seize(
>CORE_barrier_Control *the_barrier,
> --
> 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

[PATCH 0/4] bsps/shared/ofw: Bug and Coverity defect fixes

[G S Niteesh Babu]

The following series of patches fix bugs and coverity reported
defect in bsps/shared/ofw.c.

G S Niteesh Babu (4):
  bsps/shared/ofw: Fix coverity reported defects
  bsps/shared/ofw: Use memcpy instead of strncpy
  bsps/shared/ofw: Make rtems_ofw_get_effective_phandle iterative
  bsps/shared/ofw: Bug fixes

 bsps/shared/ofw/ofw.c | 35 ++-
 1 file changed, 22 insertions(+), 13 deletions(-)

-- 
2.17.1

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

[PATCH 1/4] bsps/shared/ofw: Fix coverity reported defects

[G S Niteesh Babu]

Fixed use after free and null pointer dereference defects

FIXES:
1) CID 1472601 (NULL_RETURNS)
2) CID 1472600 (USE_AFTER_FREE)
3) CID 1472599 (USE_AFTER_FREE)
4) CID 1472598 (USE_AFTER_FREE)
5) CID 1472596 (USE_AFTER_FREE)

The below two defects have to marked false positive
1) CID 1472597 (ARRAY_VS_SINGLETON)
2) CID 1472595 (ARRAY_VS_SINGLETON)
---
 bsps/shared/ofw/ofw.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/bsps/shared/ofw/ofw.c b/bsps/shared/ofw/ofw.c
index 82924b2600..fa94bfbf05 100644
--- a/bsps/shared/ofw/ofw.c
+++ b/bsps/shared/ofw/ofw.c
@@ -313,7 +313,7 @@ ssize_t rtems_ofw_get_prop_alloc(
 }
 
 if (rtems_ofw_get_prop(node, propname, *buf, len) == -1) {
-  rtems_ofw_free(buf);
+  rtems_ofw_free(*buf);
   *buf = NULL;
   return -1;
 }
@@ -344,7 +344,7 @@ ssize_t rtems_ofw_get_prop_alloc_multi(
 }
 
 if (rtems_ofw_get_prop(node, propname, *buf, len) == -1) {
-  rtems_ofw_free(buf);
+  rtems_ofw_free(*buf);
   *buf = NULL;
   return -1;
 }
@@ -373,7 +373,7 @@ ssize_t rtems_ofw_get_enc_prop_alloc(
 }
 
 if (rtems_ofw_get_enc_prop(node, propname, *buf, len) == -1) {
-  rtems_ofw_free(buf);
+  rtems_ofw_free(*buf);
   *buf = NULL;
   return -1;
 }
@@ -404,7 +404,7 @@ ssize_t rtems_ofw_get_enc_prop_alloc_multi(
 }
 
 if (rtems_ofw_get_enc_prop(node, propname, *buf, len) == -1) {
-  rtems_ofw_free(buf);
+  rtems_ofw_free(*buf);
   *buf = NULL;
   return -1;
 }
@@ -614,7 +614,7 @@ int rtems_ofw_get_reg(
 offset = rtems_fdt_phandle_to_offset(parent);
 ptr = fdt_getprop(fdtp, offset, "ranges", &len);
 
-if (len < 0) {
+if (ptr == NULL) {
   break;
 }
 
-- 
2.17.1

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

[PATCH 2/4] bsps/shared/ofw: Use memcpy instead of strncpy

[G S Niteesh Babu]

Changed rtems_ofw_get_prop to use memcpy instead of strncpy
---
 bsps/shared/ofw/ofw.c | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/bsps/shared/ofw/ofw.c b/bsps/shared/ofw/ofw.c
index fa94bfbf05..9dec310247 100644
--- a/bsps/shared/ofw/ofw.c
+++ b/bsps/shared/ofw/ofw.c
@@ -198,7 +198,15 @@ ssize_t rtems_ofw_get_prop(
 
   if (prop == NULL && strcmp(propname, "name") == 0) {
 prop = fdt_get_name(fdtp, offset, &len);
-strncpy(buf, prop, bufsize);
+
+bufsize = MIN(len, bufsize - 1);
+memcpy(buf, prop, bufsize);
+
+/* Null terminate the buffer */
+*((char *)buf + bufsize) = 0;
+
+/* Return the length of the name including the null byte */
+/* This is the behaviour in libBSD ofw_fdt_getprop */
 return len + 1;
   }
 
-- 
2.17.1

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

[PATCH 3/4] bsps/shared/ofw: Make rtems_ofw_get_effective_phandle iterative

[G S Niteesh Babu]

Refactored recursive rtems_ofw_get_effective_phandle into a
iterative function.
---
 bsps/shared/ofw/ofw.c | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/bsps/shared/ofw/ofw.c b/bsps/shared/ofw/ofw.c
index 9dec310247..e3626747fa 100644
--- a/bsps/shared/ofw/ofw.c
+++ b/bsps/shared/ofw/ofw.c
@@ -509,11 +509,12 @@ static phandle_t rtems_ofw_get_effective_phandle(
 {
   phandle_t child;
   phandle_t ref;
+  int node_offset;
 
-  for (child = rtems_ofw_child(node); child != 0; child = 
rtems_ofw_peer(child)) {
-ref = rtems_ofw_get_effective_phandle(child, xref);
-if (ref != -1)
-  return ref;
+  node_offset = fdt_path_offset(fdtp, "/");
+
+  while ((node_offset = fdt_next_node(fdtp, node_offset, NULL)) > 0) {
+child = rtems_fdt_offset_to_phandle(node_offset);
 
 if (rtems_ofw_get_enc_prop(child, "phandle", &ref, sizeof(ref)) == -1 &&
 rtems_ofw_get_enc_prop(child, "ibm,phandle", &ref, sizeof(ref)) == -1 
&&
-- 
2.17.1

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

[PATCH 4/4] bsps/shared/ofw: Bug fixes

[G S Niteesh Babu]

Fixed bugs in rtems_ofw_get_prop, rtems_ofw_get_prop_len
and removed hardcoded value.
---
 bsps/shared/ofw/ofw.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/bsps/shared/ofw/ofw.c b/bsps/shared/ofw/ofw.c
index e3626747fa..8b7f77311d 100644
--- a/bsps/shared/ofw/ofw.c
+++ b/bsps/shared/ofw/ofw.c
@@ -162,7 +162,7 @@ ssize_t rtems_ofw_get_prop_len(
 return len + 1;
   }
 
-  if (prop == NULL && strcmp(propname, "/chosen") == 0) {
+  if (prop == NULL && offset == fdt_path_offset(fdtp, "/chosen")) {
 if (strcmp(propname, "fdtbootcpu") == 0)
   return sizeof(pcell_t);
 if (strcmp(propname, "fdtmemreserv") == 0)
@@ -210,7 +210,7 @@ ssize_t rtems_ofw_get_prop(
 return len + 1;
   }
 
-  if (prop == NULL && strcmp(propname, "/chosen") == 0) {
+  if (prop == NULL && offset == fdt_path_offset(fdtp, "/chosen")) {
 if (strcmp(propname, "fdtbootcpu") == 0) {
   cpuid = cpu_to_fdt32(fdt_boot_cpuid_phys(fdtp));
   len = sizeof(cpuid);
@@ -240,7 +240,7 @@ ssize_t rtems_ofw_get_enc_prop(
 {
   ssize_t rv;
 
-  assert(len % 4 == 0);
+  assert(len % sizeof(pcell_t) == 0);
   rv = rtems_ofw_get_prop(node, prop, buf, len);
 
   if (rv < 0) {
-- 
2.17.1

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

Re: [PATCH 2/4] bsps/shared/ofw: Use memcpy instead of strncpy

[Gedare Bloom]

On Fri, Feb 5, 2021 at 10:41 AM G S Niteesh Babu 
wrote:

> Changed rtems_ofw_get_prop to use memcpy instead of strncpy
> ---
>  bsps/shared/ofw/ofw.c | 10 +-
>  1 file changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/bsps/shared/ofw/ofw.c b/bsps/shared/ofw/ofw.c
> index fa94bfbf05..9dec310247 100644
> --- a/bsps/shared/ofw/ofw.c
> +++ b/bsps/shared/ofw/ofw.c
> @@ -198,7 +198,15 @@ ssize_t rtems_ofw_get_prop(
>
>if (prop == NULL && strcmp(propname, "name") == 0) {
>  prop = fdt_get_name(fdtp, offset, &len);
> -strncpy(buf, prop, bufsize);
> +
> +bufsize = MIN(len, bufsize - 1);
>
ok, reserving 1 byte for the \0. It could be worth adding a comment here to
that effect


> +memcpy(buf, prop, bufsize);
> +
> +/* Null terminate the buffer */
> +*((char *)buf + bufsize) = 0;
>
that gets written here. looks fine to me.


> +
> +/* Return the length of the name including the null byte */
> +/* This is the behaviour in libBSD ofw_fdt_getprop */
>  return len + 1;
>
shouldn't it be bufsize+1? if it got truncated by the MIN?


>}
>
> --
> 2.17.1
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 3/4] bsps/shared/ofw: Make rtems_ofw_get_effective_phandle iterative

[Gedare Bloom]

On Fri, Feb 5, 2021 at 10:41 AM G S Niteesh Babu 
wrote:

> Refactored recursive rtems_ofw_get_effective_phandle into a
> iterative function.
> ---
>  bsps/shared/ofw/ofw.c | 9 +
>  1 file changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/bsps/shared/ofw/ofw.c b/bsps/shared/ofw/ofw.c
> index 9dec310247..e3626747fa 100644
> --- a/bsps/shared/ofw/ofw.c
> +++ b/bsps/shared/ofw/ofw.c
> @@ -509,11 +509,12 @@ static phandle_t rtems_ofw_get_effective_phandle(
>  {
>phandle_t child;
>phandle_t ref;
> +  int node_offset;
>
> -  for (child = rtems_ofw_child(node); child != 0; child =
> rtems_ofw_peer(child)) {
> -ref = rtems_ofw_get_effective_phandle(child, xref);
> -if (ref != -1)
> -  return ref;
> +  node_offset = fdt_path_offset(fdtp, "/");
> +
> +  while ((node_offset = fdt_next_node(fdtp, node_offset, NULL)) > 0) {
> +child = rtems_fdt_offset_to_phandle(node_offset);
>
> Assuming this works, it is much better now :) Thanks.


>  if (rtems_ofw_get_enc_prop(child, "phandle", &ref, sizeof(ref)) == -1
> &&
>  rtems_ofw_get_enc_prop(child, "ibm,phandle", &ref, sizeof(ref))
> == -1 &&
> --
> 2.17.1
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 0/4] bsps/shared/ofw: Bug and Coverity defect fixes

[Gedare Bloom]

I'm good with everything except my comment on #2

On Fri, Feb 5, 2021 at 10:41 AM G S Niteesh Babu 
wrote:

> The following series of patches fix bugs and coverity reported
> defect in bsps/shared/ofw.c.
>
> G S Niteesh Babu (4):
>   bsps/shared/ofw: Fix coverity reported defects
>   bsps/shared/ofw: Use memcpy instead of strncpy
>   bsps/shared/ofw: Make rtems_ofw_get_effective_phandle iterative
>   bsps/shared/ofw: Bug fixes
>
>  bsps/shared/ofw/ofw.c | 35 ++-
>  1 file changed, 22 insertions(+), 13 deletions(-)
>
> --
> 2.17.1
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Standalone repository for libnetworking stack

[Vijay Kumar Banerjee]

Hello,

I'm currently working on separating the libnetworking stack into its
standalone repository that can be built separately with waf. The current
status of the project is that I have a working rtems-libnetworking
repository [1] that builds with waf (hasn't been tested with any test cases
yet). And In my fork of RTEMS I have separated the libnetworking stack [2].

I need suggestions with the following questions:

1. What to do with the codes in RTEMS outside the libnetworking stack,
which uses the networking library. Libraries for example libpppd uses
libnetworking. Do we want to shift these to the separate repository for
libnetworking or do we want to keep them in RTEMS and use the waf system to
selectively built those when the libnetworking is available in PREFIX. We
can add a common header file that #defines RTEMS_NETWORKING, so that the
related codes can be built and used.

2. There are a few header files in cpukit/include that are required by the
libnetworking stack. Currently the rtems-libnetworking is building in sort
of a hackish way by using the header file from the RTEMS source directory.
Do we want to add these header files (like tftp.h) and related source files
to the libnetworking directory? The other way to use them would be to
install the required headers in the PREFIX and use them from libnetworking.

Any suggestions regarding these questions is greatly appreciated.


Best regards,
Vijay

[1]: https://github.com/thelunatic/rtems-libnetworking
[2]: https://github.com/thelunatic/rtems/tree/no-libnet
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 3/3] score: Add barrier thread queue operations

[Sebastian Huber]

On 05/02/2021 18:16, Gedare Bloom wrote:



On Fri, Feb 5, 2021 at 6:37 AM Sebastian Huber 
> wrote:


This fixes a missing decrement of the number of waiting threads
during a
barrier wait timeout.

Close #4230.

Is this bug a problem that should be fixed on any open branch(es)?
Back porting it to RTEMS 5 should be easy. I am not sure about RTEMS 
4.11. This version has no benefits compared to RTEMS 5.


--
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: Standalone repository for libnetworking stack

[Christian Mauderer]

Hello Vijay,

On 05/02/2021 19:41, Vijay Kumar Banerjee wrote:

Hello,

I'm currently working on separating the libnetworking stack into its 
standalone repository that can be built separately with waf. The current 
status of the project is that I have a working rtems-libnetworking 
repository [1] that builds with waf (hasn't been tested with any test 
cases yet). And In my fork of RTEMS I have separated the libnetworking 
stack [2].


Sounds like an interesting work. If I didn't miss an earlier discussion: 
I think the name might could trigger one. It gives the impression that 
it is _the_ networking stack to use. But for newer BSPs most of the time 
libbsd is the better choice.




I need suggestions with the following questions:

1. What to do with the codes in RTEMS outside the libnetworking stack, 
which uses the networking library. Libraries for example libpppd uses 
libnetworking. Do we want to shift these to the separate repository for 
libnetworking or do we want to keep them in RTEMS and use the waf system 
to selectively built those when the libnetworking is available in 
PREFIX. We can add a common header file that #defines RTEMS_NETWORKING, 
so that the related codes can be built and used.


I think it depends:

Can they be used with libbsd or only with the legacy stack?

If they can be used with libbsd: Can they be build without a networking 
stack? In that case it might would be possible to build them in RTEMS 
and link them later with either libbsd, with libnetworking or (maybe) 
some-when with lwIP. I don't think there is a reason to not build them 
for any BSP if they can be build without a networking stack.


If they can't be used with libbsd (or another stack) I would suggest to 
keep them together with the legacy stack in your new libnetworking 
repository.




2. There are a few header files in cpukit/include that are required by 
the libnetworking stack. Currently the rtems-libnetworking is building 
in sort of a hackish way by using the header file from the RTEMS source 
directory. Do we want to add these header files (like tftp.h) and 
related source files to the libnetworking directory? The other way to 
use them would be to install the required headers in the PREFIX and use 
them from libnetworking.


If I understand correctly, the headers are not installed? In that case: 
Who else uses these headers? If no one except for the network stack 
needs them: Move them to your new library.


In case of the tftp.h: It seems that this file is installed, isn't it? 
So why can't you just use it from libnetworking?


Best regards

Christian



Any suggestions regarding these questions is greatly appreciated.


Best regards,
Vijay

[1]: https://github.com/thelunatic/rtems-libnetworking 

[2]: https://github.com/thelunatic/rtems/tree/no-libnet 



___
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 2/4] bsps/shared/ofw: Use memcpy instead of strncpy

[Christian Mauderer]

On 05/02/2021 19:22, Gedare Bloom wrote:



On Fri, Feb 5, 2021 at 10:41 AM G S Niteesh Babu > wrote:


Changed rtems_ofw_get_prop to use memcpy instead of strncpy
---
  bsps/shared/ofw/ofw.c | 10 +-
  1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/bsps/shared/ofw/ofw.c b/bsps/shared/ofw/ofw.c
index fa94bfbf05..9dec310247 100644
--- a/bsps/shared/ofw/ofw.c
+++ b/bsps/shared/ofw/ofw.c
@@ -198,7 +198,15 @@ ssize_t rtems_ofw_get_prop(

    if (prop == NULL && strcmp(propname, "name") == 0) {
      prop = fdt_get_name(fdtp, offset, &len);
-    strncpy(buf, prop, bufsize);
+
+    bufsize = MIN(len, bufsize - 1);

ok, reserving 1 byte for the \0. It could be worth adding a comment here 
to that effect


Is the content of that property really _allways_ a string? Isn't it 
possible to read some references or similar with it?


If it is always a string, I might have made a useless suggestion. In 
that case it might is more efficient and readable to just keep the 
strncpy. Depending on the use case, maybe using strlcpy instead of 
strncpy could be a good idea to guarantee the \0 termination.




+    memcpy(buf, prop, bufsize);
+
+    /* Null terminate the buffer */
+    *((char *)buf + bufsize) = 0;

that gets written here. looks fine to me.

+
+    /* Return the length of the name including the null byte */
+    /* This is the behaviour in libBSD ofw_fdt_getprop */
      return len + 1;

shouldn't it be bufsize+1? if it got truncated by the MIN?

    }

-- 
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: Standalone repository for libnetworking stack

[Joel Sherrill]

On Fri, Feb 5, 2021 at 2:54 PM Christian Mauderer  wrote:

> Hello Vijay,
>
> On 05/02/2021 19:41, Vijay Kumar Banerjee wrote:
> > Hello,
> >
> > I'm currently working on separating the libnetworking stack into its
> > standalone repository that can be built separately with waf. The current
> > status of the project is that I have a working rtems-libnetworking
> > repository [1] that builds with waf (hasn't been tested with any test
> > cases yet). And In my fork of RTEMS I have separated the libnetworking
> > stack [2].
>
> Sounds like an interesting work. If I didn't miss an earlier discussion:
> I think the name might could trigger one. It gives the impression that
> it is _the_ networking stack to use. But for newer BSPs most of the time
> libbsd is the better choice.
>

We could make it painful and obvious using something like
rtems-legacy-networking :)

I assume you are also taking all legacy network drivers with you.

One random thought is whether this should only build for specific BSPs. We
currently can build the stack for nearly all architectures but I don't
think that
realistically there are BSPs which run it on all architectures. Should
there be
a whitelist of supported BSPs?

And I used "supported" quite loosely. I expect that other than a
small number of BSPs you can check on simulators, this is not going to
be heavily tested beyond building. This is not a criticism. I think it is
just a reality of doing something better than removing it entirely.


> >
> > I need suggestions with the following questions:
> >
> > 1. What to do with the codes in RTEMS outside the libnetworking stack,
> > which uses the networking library. Libraries for example libpppd uses
> > libnetworking. Do we want to shift these to the separate repository for
> > libnetworking or do we want to keep them in RTEMS and use the waf system
> > to selectively built those when the libnetworking is available in
> > PREFIX. We can add a common header file that #defines RTEMS_NETWORKING,
> > so that the related codes can be built and used.
>
> I think it depends:
>
> Can they be used with libbsd or only with the legacy stack?
>

I thought the point of having the network headers in newlib was to enable
user space networking applications that could build independent of the
network stack in use. I think these should stay in rtems/ as much as
possible.


>
> If they can be used with libbsd: Can they be build without a networking
> stack? In that case it might would be possible to build them in RTEMS
> and link them later with either libbsd, with libnetworking or (maybe)
> some-when with lwIP. I don't think there is a reason to not build them
> for any BSP if they can be build without a networking stack.
>

Yes. This is how it is supposed to work and should with libbsd now.

>
> If they can't be used with libbsd (or another stack) I would suggest to
> keep them together with the legacy stack in your new libnetworking
> repository.
>

+1

>
> >
> > 2. There are a few header files in cpukit/include that are required by
> > the libnetworking stack. Currently the rtems-libnetworking is building
> > in sort of a hackish way by using the header file from the RTEMS source
> > directory. Do we want to add these header files (like tftp.h) and
> > related source files to the libnetworking directory? The other way to
> > use them would be to install the required headers in the PREFIX and use
> > them from libnetworking.
>
> If I understand correctly, the headers are not installed? In that case:
> Who else uses these headers? If no one except for the network stack
> needs them: Move them to your new library.
>

+1

>
> In case of the tftp.h: It seems that this file is installed, isn't it?
> So why can't you just use it from libnetworking?
>

Hmm... that appears to be used only by the tftp client filesystem. That
should
be in libfs/src really.  There is also an ftp client filesystem which also
needs to
move. They SHOULD work independent of the network stack.

Move those files so either stack can use them.

I'm thrilled to see this happening.

--joel


> Best regards
>
> Christian
>
> >
> > Any suggestions regarding these questions is greatly appreciated.
> >
> >
> > Best regards,
> > Vijay
> >
> > [1]: https://github.com/thelunatic/rtems-libnetworking
> > 
> > [2]: https://github.com/thelunatic/rtems/tree/no-libnet
> > 
> >
> > ___
> > 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: Standalone repository for libnetworking stack

[Chris Johns]

On 6/2/21 8:28 am, Joel Sherrill wrote:
> On Fri, Feb 5, 2021 at 2:54 PM Christian Mauderer  > wrote:
> 
> Hello Vijay,
> 
> On 05/02/2021 19:41, Vijay Kumar Banerjee wrote:
> > Hello,
> >
> > I'm currently working on separating the libnetworking stack into its
> > standalone repository that can be built separately with waf. The current
> > status of the project is that I have a working rtems-libnetworking
> > repository [1] that builds with waf (hasn't been tested with any test
> > cases yet). And In my fork of RTEMS I have separated the libnetworking
> > stack [2].

If you have not already done so I suggest you create repos in your personal area
on dispatch.rtems.org and these will appear on the cgit page. It is a simple way
to get exposure to the work.

> Sounds like an interesting work. If I didn't miss an earlier discussion:
> I think the name might could trigger one. It gives the impression that
> it is _the_ networking stack to use. But for newer BSPs most of the time
> libbsd is the better choice.
> 
> 
> We could make it painful and obvious using something like 
> rtems-legacy-networking :) 

.. or rtems-net-legacy ... small, clear and simple.

> I assume you are also taking all legacy network drivers with you.

Yes this is a good point. They will have to move as well. I hope this does not
create links back into BSP specific headers that are not currently being 
installed.

> One random thought is whether this should only build for specific BSPs. We
> currently can build the stack for nearly all architectures but I don't think 
> that
> realistically there are BSPs which run it on all architectures. Should there 
> be
> a whitelist of supported BSPs?

There are BSPs where the drivers are not in RTEMS because of chip vendor
licensing issues. Why not follow the rtems-libbsd model?

> And I used "supported" quite loosely. I expect that other than a 
> small number of BSPs you can check on simulators, this is not going to
> be heavily tested beyond building. This is not a criticism. I think it is
> just a reality of doing something better than removing it entirely.

If it is tested when split and then maintained so it builds it should stay in a
reasonable state. We just need to state clearly our intentions and if someone
really needs support there are commercial support options.

> > I need suggestions with the following questions:
> >
> > 1. What to do with the codes in RTEMS outside the libnetworking stack,
> > which uses the networking library. Libraries for example libpppd uses
> > libnetworking. Do we want to shift these to the separate repository for
> > libnetworking or do we want to keep them in RTEMS and use the waf system
> > to selectively built those when the libnetworking is available in
> > PREFIX. We can add a common header file that #defines RTEMS_NETWORKING,
> > so that the related codes can be built and used.
> 
> I think it depends:
> 
> Can they be used with libbsd or only with the legacy stack?
> 
> I thought the point of having the network headers in newlib was to enable
> user space networking applications that could build independent of the
> network stack in use. I think these should stay in rtems/ as much as possible.

Do we need to audit which pieces are generic networking applications and which
are tied to libnetworking. For example libbsd has an NFS network client and so
does the legacy stack.

> If they can be used with libbsd: Can they be build without a networking
> stack? In that case it might would be possible to build them in RTEMS
> and link them later with either libbsd, with libnetworking or (maybe)
> some-when with lwIP. I don't think there is a reason to not build them
> for any BSP if they can be build without a networking stack.
> 
> Yes. This is how it is supposed to work and should with libbsd now. 

This is also my understanding.

> If they can't be used with libbsd (or another stack) I would suggest to
> keep them together with the legacy stack in your new libnetworking
> repository.
> 
> 
> +1 

+1

> > 2. There are a few header files in cpukit/include that are required by
> > the libnetworking stack. Currently the rtems-libnetworking is building
> > in sort of a hackish way by using the header file from the RTEMS source
> > directory. Do we want to add these header files (like tftp.h) and
> > related source files to the libnetworking directory? The other way to
> > use them would be to install the required headers in the PREFIX and use
> > them from libnetworking.
> 
> If I understand correctly, the headers are not installed? In that case:
> Who else uses these headers? If no one except for the network stack
> needs them: Move them to your new library.
> 
> +1 

+1

> In case of the tftp.h: It seems that this file is installed, isn't it?
> So why can'

Re: [PATCH 3/3] score: Add barrier thread queue operations

[Gedare Bloom]

On Fri, Feb 5, 2021 at 11:57 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> On 05/02/2021 18:16, Gedare Bloom wrote:
>
> >
> > On Fri, Feb 5, 2021 at 6:37 AM Sebastian Huber
> >  > > wrote:
> >
> > This fixes a missing decrement of the number of waiting threads
> > during a
> > barrier wait timeout.
> >
> > Close #4230.
> >
> > Is this bug a problem that should be fixed on any open branch(es)?
> Back porting it to RTEMS 5 should be easy. I am not sure about RTEMS
> 4.11. This version has no benefits compared to RTEMS 5.
>
> OK. I think this is consistent with our maintenance policies anyway.
(Although if we in fact do start to release faster, we might need to
maintain more than 1 release branch at a time.)


> --
> 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: Standalone repository for libnetworking stack

[Joel Sherrill]

On Fri, Feb 5, 2021 at 4:41 PM Chris Johns  wrote:

> On 6/2/21 8:28 am, Joel Sherrill wrote:
> > On Fri, Feb 5, 2021 at 2:54 PM Christian Mauderer  > > wrote:
> >
> > Hello Vijay,
> >
> > On 05/02/2021 19:41, Vijay Kumar Banerjee wrote:
> > > Hello,
> > >
> > > I'm currently working on separating the libnetworking stack into
> its
> > > standalone repository that can be built separately with waf. The
> current
> > > status of the project is that I have a working rtems-libnetworking
> > > repository [1] that builds with waf (hasn't been tested with any
> test
> > > cases yet). And In my fork of RTEMS I have separated the
> libnetworking
> > > stack [2].
>
> If you have not already done so I suggest you create repos in your
> personal area
> on dispatch.rtems.org and these will appear on the cgit page. It is a
> simple way
> to get exposure to the work.
>
> > Sounds like an interesting work. If I didn't miss an earlier
> discussion:
> > I think the name might could trigger one. It gives the impression
> that
> > it is _the_ networking stack to use. But for newer BSPs most of the
> time
> > libbsd is the better choice.
> >
> >
> > We could make it painful and obvious using something like
> > rtems-legacy-networking :)
>
> .. or rtems-net-legacy ... small, clear and simple.
>
> > I assume you are also taking all legacy network drivers with you.
>
> Yes this is a good point. They will have to move as well. I hope this does
> not
> create links back into BSP specific headers that are not currently being
> installed.
>
> > One random thought is whether this should only build for specific BSPs.
> We
> > currently can build the stack for nearly all architectures but I don't
> think that
> > realistically there are BSPs which run it on all architectures. Should
> there be
> > a whitelist of supported BSPs?
>
> There are BSPs where the drivers are not in RTEMS because of chip vendor
> licensing issues. Why not follow the rtems-libbsd model?
>

And by this, what do you mean? Be able to build it even if there are no BSP
specific drivers available?


>
> > And I used "supported" quite loosely. I expect that other than a
> > small number of BSPs you can check on simulators, this is not going to
> > be heavily tested beyond building. This is not a criticism. I think it is
> > just a reality of doing something better than removing it entirely.
>
> If it is tested when split and then maintained so it builds it should stay
> in a
> reasonable state. We just need to state clearly our intentions and if
> someone
> really needs support there are commercial support options.
>
> > > I need suggestions with the following questions:
> > >
> > > 1. What to do with the codes in RTEMS outside the libnetworking
> stack,
> > > which uses the networking library. Libraries for example libpppd
> uses
> > > libnetworking. Do we want to shift these to the separate
> repository for
> > > libnetworking or do we want to keep them in RTEMS and use the waf
> system
> > > to selectively built those when the libnetworking is available in
> > > PREFIX. We can add a common header file that #defines
> RTEMS_NETWORKING,
> > > so that the related codes can be built and used.
> >
> > I think it depends:
> >
> > Can they be used with libbsd or only with the legacy stack?
> >
> > I thought the point of having the network headers in newlib was to enable
> > user space networking applications that could build independent of the
> > network stack in use. I think these should stay in rtems/ as much as
> possible.
>
> Do we need to audit which pieces are generic networking applications and
> which
> are tied to libnetworking. For example libbsd has an NFS network client
> and so
> does the legacy stack.
>

Probably. If they are in both, move the one in rtems/ to the legacy kit.

>
> > If they can be used with libbsd: Can they be build without a
> networking
> > stack? In that case it might would be possible to build them in RTEMS
> > and link them later with either libbsd, with libnetworking or (maybe)
> > some-when with lwIP. I don't think there is a reason to not build
> them
> > for any BSP if they can be build without a networking stack.
> >
> > Yes. This is how it is supposed to work and should with libbsd now.
>
> This is also my understanding.
>
> > If they can't be used with libbsd (or another stack) I would suggest
> to
> > keep them together with the legacy stack in your new libnetworking
> > repository.
> >
> >
> > +1
>
> +1
>
> > > 2. There are a few header files in cpukit/include that are
> required by
> > > the libnetworking stack. Currently the rtems-libnetworking is
> building
> > > in sort of a hackish way by using the header file from the RTEMS
> source
> > > directory. Do we want to add these header files (like tftp.h) and
> > > related source files to the libnetwor

Re: Standalone repository for libnetworking stack

[Vijay Kumar Banerjee]

Hello Christian, Joel, Chris,

On Fri, Feb 5, 2021 at 3:41 PM Chris Johns  wrote:
>
> On 6/2/21 8:28 am, Joel Sherrill wrote:
> > On Fri, Feb 5, 2021 at 2:54 PM Christian Mauderer  > > wrote:
> >
> > Hello Vijay,
> >
> > On 05/02/2021 19:41, Vijay Kumar Banerjee wrote:
> > > Hello,
> > >
> > > I'm currently working on separating the libnetworking stack into its
> > > standalone repository that can be built separately with waf. The 
> > current
> > > status of the project is that I have a working rtems-libnetworking
> > > repository [1] that builds with waf (hasn't been tested with any test
> > > cases yet). And In my fork of RTEMS I have separated the libnetworking
> > > stack [2].
>
> If you have not already done so I suggest you create repos in your personal 
> area
> on dispatch.rtems.org and these will appear on the cgit page. It is a simple 
> way
> to get exposure to the work.
>
I do have some repos in my area in dispatch.rtems.org but for some
reason they don't appear in git.rtems.org page that's why I pushed it
in github. Am I possibly missing some step?

> > Sounds like an interesting work. If I didn't miss an earlier discussion:
> > I think the name might could trigger one. It gives the impression that
> > it is _the_ networking stack to use. But for newer BSPs most of the time
> > libbsd is the better choice.
> >
That's a good point!

> >
> > We could make it painful and obvious using something like
> > rtems-legacy-networking :)
>
> .. or rtems-net-legacy ... small, clear and simple.

rtems-net-legacy sounds right, I'll rename.

>
> > I assume you are also taking all legacy network drivers with you.
>
> Yes this is a good point. They will have to move as well. I hope this does not
> create links back into BSP specific headers that are not currently being 
> installed.
>
> > One random thought is whether this should only build for specific BSPs. We
> > currently can build the stack for nearly all architectures but I don't 
> > think that
> > realistically there are BSPs which run it on all architectures. Should 
> > there be
> > a whitelist of supported BSPs?
>
> There are BSPs where the drivers are not in RTEMS because of chip vendor
> licensing issues. Why not follow the rtems-libbsd model?
>
Currently it builds for all BSPs, like libbsd.

> > And I used "supported" quite loosely. I expect that other than a
> > small number of BSPs you can check on simulators, this is not going to
> > be heavily tested beyond building. This is not a criticism. I think it is
> > just a reality of doing something better than removing it entirely.
>
> If it is tested when split and then maintained so it builds it should stay in 
> a
> reasonable state. We just need to state clearly our intentions and if someone
> really needs support there are commercial support options.
>
> > > I need suggestions with the following questions:
> > >
> > > 1. What to do with the codes in RTEMS outside the libnetworking stack,
> > > which uses the networking library. Libraries for example libpppd uses
> > > libnetworking. Do we want to shift these to the separate repository 
> > for
> > > libnetworking or do we want to keep them in RTEMS and use the waf 
> > system
> > > to selectively built those when the libnetworking is available in
> > > PREFIX. We can add a common header file that #defines 
> > RTEMS_NETWORKING,
> > > so that the related codes can be built and used.
> >
> > I think it depends:
> >
> > Can they be used with libbsd or only with the legacy stack?
> >
> > I thought the point of having the network headers in newlib was to enable
> > user space networking applications that could build independent of the
> > network stack in use. I think these should stay in rtems/ as much as 
> > possible.
>
> Do we need to audit which pieces are generic networking applications and which
> are tied to libnetworking. For example libbsd has an NFS network client and so
> does the legacy stack.
>
> > If they can be used with libbsd: Can they be build without a networking
> > stack? In that case it might would be possible to build them in RTEMS
> > and link them later with either libbsd, with libnetworking or (maybe)
> > some-when with lwIP. I don't think there is a reason to not build them
> > for any BSP if they can be build without a networking stack.
> >
> > Yes. This is how it is supposed to work and should with libbsd now.
>
> This is also my understanding.

Understood. I'm not sure if they're used with libbsd but I think
they're not as they're only built with RTEMS_NETWORKING enabled. I'll
move them to the new repo.
>
> > If they can't be used with libbsd (or another stack) I would suggest to
> > keep them together with the legacy stack in your new libnetworking
> > repository.
> >
> >
> > +1
>
> +1
>.

Ok.
> > > 2. There are a few header files in cpukit/include that ar

Re: Standalone repository for libnetworking stack

[Joel Sherrill]

On Fri, Feb 5, 2021, 5:17 PM Vijay Kumar Banerjee  wrote:

> Hello Christian, Joel, Chris,
>
> On Fri, Feb 5, 2021 at 3:41 PM Chris Johns  wrote:
> >
> > On 6/2/21 8:28 am, Joel Sherrill wrote:
> > > On Fri, Feb 5, 2021 at 2:54 PM Christian Mauderer  > > > wrote:
> > >
> > > Hello Vijay,
> > >
> > > On 05/02/2021 19:41, Vijay Kumar Banerjee wrote:
> > > > Hello,
> > > >
> > > > I'm currently working on separating the libnetworking stack into
> its
> > > > standalone repository that can be built separately with waf. The
> current
> > > > status of the project is that I have a working
> rtems-libnetworking
> > > > repository [1] that builds with waf (hasn't been tested with any
> test
> > > > cases yet). And In my fork of RTEMS I have separated the
> libnetworking
> > > > stack [2].
> >
> > If you have not already done so I suggest you create repos in your
> personal area
> > on dispatch.rtems.org and these will appear on the cgit page. It is a
> simple way
> > to get exposure to the work.
> >
> I do have some repos in my area in dispatch.rtems.org but for some
> reason they don't appear in git.rtems.org page that's why I pushed it
> in github. Am I possibly missing some step?
>
> > > Sounds like an interesting work. If I didn't miss an earlier
> discussion:
> > > I think the name might could trigger one. It gives the impression
> that
> > > it is _the_ networking stack to use. But for newer BSPs most of
> the time
> > > libbsd is the better choice.
> > >
> That's a good point!
>
> > >
> > > We could make it painful and obvious using something like
> > > rtems-legacy-networking :)
> >
> > .. or rtems-net-legacy ... small, clear and simple.
>
> rtems-net-legacy sounds right, I'll rename.
>
> >
> > > I assume you are also taking all legacy network drivers with you.
> >
> > Yes this is a good point. They will have to move as well. I hope this
> does not
> > create links back into BSP specific headers that are not currently being
> installed.
> >
> > > One random thought is whether this should only build for specific
> BSPs. We
> > > currently can build the stack for nearly all architectures but I don't
> think that
> > > realistically there are BSPs which run it on all architectures. Should
> there be
> > > a whitelist of supported BSPs?
> >
> > There are BSPs where the drivers are not in RTEMS because of chip vendor
> > licensing issues. Why not follow the rtems-libbsd model?
> >
> Currently it builds for all BSPs, like libbsd.
>
> > > And I used "supported" quite loosely. I expect that other than a
> > > small number of BSPs you can check on simulators, this is not going to
> > > be heavily tested beyond building. This is not a criticism. I think it
> is
> > > just a reality of doing something better than removing it entirely.
> >
> > If it is tested when split and then maintained so it builds it should
> stay in a
> > reasonable state. We just need to state clearly our intentions and if
> someone
> > really needs support there are commercial support options.
> >
> > > > I need suggestions with the following questions:
> > > >
> > > > 1. What to do with the codes in RTEMS outside the libnetworking
> stack,
> > > > which uses the networking library. Libraries for example libpppd
> uses
> > > > libnetworking. Do we want to shift these to the separate
> repository for
> > > > libnetworking or do we want to keep them in RTEMS and use the
> waf system
> > > > to selectively built those when the libnetworking is available in
> > > > PREFIX. We can add a common header file that #defines
> RTEMS_NETWORKING,
> > > > so that the related codes can be built and used.
> > >
> > > I think it depends:
> > >
> > > Can they be used with libbsd or only with the legacy stack?
> > >
> > > I thought the point of having the network headers in newlib was to
> enable
> > > user space networking applications that could build independent of the
> > > network stack in use. I think these should stay in rtems/ as much as
> possible.
> >
> > Do we need to audit which pieces are generic networking applications and
> which
> > are tied to libnetworking. For example libbsd has an NFS network client
> and so
> > does the legacy stack.
> >
> > > If they can be used with libbsd: Can they be build without a
> networking
> > > stack? In that case it might would be possible to build them in
> RTEMS
> > > and link them later with either libbsd, with libnetworking or
> (maybe)
> > > some-when with lwIP. I don't think there is a reason to not build
> them
> > > for any BSP if they can be build without a networking stack.
> > >
> > > Yes. This is how it is supposed to work and should with libbsd now.
> >
> > This is also my understanding.
>
> Understood. I'm not sure if they're used with libbsd but I think
> they're not as they're only built with RTEMS_NETWORKING enabled. I'll
> move them to the new repo.
>

Re: spcontext01 failure

[Richi Dubey]

Thank you for the help.

I wanted to make sure that the SMP Strong APA scheduler works on the single
processor tests as well. Is there any bsp and debugger which I can use to
check this?

On Fri, Feb 5, 2021 at 11:21 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> On 05/02/2021 06:26, Richi Dubey wrote:
>
> > Also, I forgot to mention that I ran the qemu system arm like this:
> >
> > :~/quick-start/CurrentMaster/rtems/6/bin$ qemu-system-arm -net none
> > -nographic -M realview-pbx-a9 -m 256M -kernel
> >
> ~/quick-start/CurrentMaster/build/bsp/arm-rtems6/c/realview_pbx_a9_qemu/testsuites/samples/unlimited.exe
>
> > -smp 4 -s -S
> >
> If  you start applications configured for one processor on more than one
> processor on arm, then you have currently an undefined behaviour.
>
> --
> 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 3/4] bsps/shared/ofw: Make rtems_ofw_get_effective_phandle iterative

[Niteesh G. S.]

Hello Gedare,

On Fri, Feb 5, 2021 at 11:53 PM Gedare Bloom  wrote:

>
>
> On Fri, Feb 5, 2021 at 10:41 AM G S Niteesh Babu 
> wrote:
>
>> Refactored recursive rtems_ofw_get_effective_phandle into a
>> iterative function.
>> ---
>>  bsps/shared/ofw/ofw.c | 9 +
>>  1 file changed, 5 insertions(+), 4 deletions(-)
>>
>> diff --git a/bsps/shared/ofw/ofw.c b/bsps/shared/ofw/ofw.c
>> index 9dec310247..e3626747fa 100644
>> --- a/bsps/shared/ofw/ofw.c
>> +++ b/bsps/shared/ofw/ofw.c
>> @@ -509,11 +509,12 @@ static phandle_t rtems_ofw_get_effective_phandle(
>>  {
>>phandle_t child;
>>phandle_t ref;
>> +  int node_offset;
>>
>> -  for (child = rtems_ofw_child(node); child != 0; child =
>> rtems_ofw_peer(child)) {
>> -ref = rtems_ofw_get_effective_phandle(child, xref);
>> -if (ref != -1)
>> -  return ref;
>> +  node_offset = fdt_path_offset(fdtp, "/");
>> +
>> +  while ((node_offset = fdt_next_node(fdtp, node_offset, NULL)) > 0) {
>> +child = rtems_fdt_offset_to_phandle(node_offset);
>>
>> Assuming this works, it is much better now :) Thanks.
>
Yes, it does. I checked it by creating a small test outside of RTEMS using
real DTB
files (Rpi.dtb and Beagle.dtb). I basically mmap the dtb file and
initialize fdtp with the
mapped address, and use this with libFDT and ofw.c to test and debug. This
creates
a much easier env to work with. Finally, when satisfied with the results I
test them
on real hardware.

Thanks,
Niteesh.


>
>>  if (rtems_ofw_get_enc_prop(child, "phandle", &ref, sizeof(ref)) ==
>> -1 &&
>>  rtems_ofw_get_enc_prop(child, "ibm,phandle", &ref, sizeof(ref))
>> == -1 &&
>> --
>> 2.17.1
>>
>>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 2/4] bsps/shared/ofw: Use memcpy instead of strncpy

[Niteesh G. S.]

Hello Christian,

On Sat, Feb 6, 2021 at 2:33 AM Christian Mauderer  wrote:

> On 05/02/2021 19:22, Gedare Bloom wrote:
> >
> >
> > On Fri, Feb 5, 2021 at 10:41 AM G S Niteesh Babu  > > wrote:
> >
> > Changed rtems_ofw_get_prop to use memcpy instead of strncpy
> > ---
> >   bsps/shared/ofw/ofw.c | 10 +-
> >   1 file changed, 9 insertions(+), 1 deletion(-)
> >
> > diff --git a/bsps/shared/ofw/ofw.c b/bsps/shared/ofw/ofw.c
> > index fa94bfbf05..9dec310247 100644
> > --- a/bsps/shared/ofw/ofw.c
> > +++ b/bsps/shared/ofw/ofw.c
> > @@ -198,7 +198,15 @@ ssize_t rtems_ofw_get_prop(
> >
> > if (prop == NULL && strcmp(propname, "name") == 0) {
> >   prop = fdt_get_name(fdtp, offset, &len);
> > -strncpy(buf, prop, bufsize);
> > +
> > +bufsize = MIN(len, bufsize - 1);
> >
> > ok, reserving 1 byte for the \0. It could be worth adding a comment here
> > to that effect
>
> Is the content of that property really _allways_ a string? Isn't it
> possible to read some references or similar with it?
>

Yes in this case it is always a string since we check if the propname ==
"name"
In other cases we use bcopy. I wanted to get this to your attention but
then I
confused myself with endianness and thought it will still be an issue.

And as per the device tree spec, the node name is 1-31 chars length,
consists
only of ASCII chars(Device tree spec table 2.1) and is null-terminated.

If it is always a string, I might have made a useless suggestion. In
> that case it might is more efficient and readable to just keep the
> strncpy. Depending on the use case, maybe using strlcpy instead of
> strncpy could be a good idea to guarantee the \0 termination.
>

As per docs, strlcpy  is  not  present  in glibc and is not standardized by
POSIX,
so is it okay to use that?
If not I can use strncpy with a check like this

strncpy(buf, str, buflen - 1);

   if (buflen > 0)
   buf[buflen - 1]= '\0';
This ensures the buffer is always null terminated.



> >
> > +memcpy(buf, prop, bufsize);
> > +
> > +/* Null terminate the buffer */
> > +*((char *)buf + bufsize) = 0;
> >
> > that gets written here. looks fine to me.
> >
> > +
> > +/* Return the length of the name including the null byte */
> > +/* This is the behaviour in libBSD ofw_fdt_getprop */
> >   return len + 1;
> >
> > shouldn't it be bufsize+1? if it got truncated by the MIN?
> >
> > }
> >
> > --
> > 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 2/4] bsps/shared/ofw: Use memcpy instead of strncpy

[Niteesh G. S.]

On Fri, Feb 5, 2021 at 11:52 PM Gedare Bloom  wrote:

>
>
> On Fri, Feb 5, 2021 at 10:41 AM G S Niteesh Babu 
> wrote:
>
>> Changed rtems_ofw_get_prop to use memcpy instead of strncpy
>> ---
>>  bsps/shared/ofw/ofw.c | 10 +-
>>  1 file changed, 9 insertions(+), 1 deletion(-)
>>
>> diff --git a/bsps/shared/ofw/ofw.c b/bsps/shared/ofw/ofw.c
>> index fa94bfbf05..9dec310247 100644
>> --- a/bsps/shared/ofw/ofw.c
>> +++ b/bsps/shared/ofw/ofw.c
>> @@ -198,7 +198,15 @@ ssize_t rtems_ofw_get_prop(
>>
>>if (prop == NULL && strcmp(propname, "name") == 0) {
>>  prop = fdt_get_name(fdtp, offset, &len);
>> -strncpy(buf, prop, bufsize);
>> +
>> +bufsize = MIN(len, bufsize - 1);
>>
> ok, reserving 1 byte for the \0. It could be worth adding a comment here
> to that effect
>
Will do.

> +memcpy(buf, prop, bufsize);
>> +
>> +/* Null terminate the buffer */
>> +*((char *)buf + bufsize) = 0;
>>
> that gets written here. looks fine to me.
>
>
>> +
>> +/* Return the length of the name including the null byte */
>> +/* This is the behaviour in libBSD ofw_fdt_getprop */
>>  return len + 1;
>>
> shouldn't it be bufsize+1? if it got truncated by the MIN?
>

We have to return the size of the value instead of the amount copied.
https://www.gsp.com/cgi-bin/man.cgi?section=9&topic=OF_GETPROP

   }
>>
>> --
>> 2.17.1
>>
>>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel