[PATCH 2/3] bsp-howto/console: Remove reference to deprecated function

[Matthew Joyce]

From: Matt Joyce 

---
 bsp-howto/console.rst | 7 ---
 1 file changed, 7 deletions(-)

diff --git a/bsp-howto/console.rst b/bsp-howto/console.rst
index 1ead39e..71e156d 100644
--- a/bsp-howto/console.rst
+++ b/bsp-howto/console.rst
@@ -505,13 +505,6 @@ The :c:func:`console_initialize()` function may look like 
this:
 handler = _driver_handler_polled;
   #endif
 
-  /*
-   * Initialize the Termios infrastructure.  If Termios has already
-   * been initialized by another device driver, then this call will
-   * have no effect.
-   */
-  rtems_termios_initialize();
-
   /* Initialize each device */
   for ( i = 0; i < RTEMS_ARRAY_SIZE( driver_context_table ) ; ++i ) {
 my_driver_context *ctx;
-- 
2.35.3

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

[PATCH 1/3] bsp-howto/console: Remove reference to old build system

[Matthew Joyce]

From: Matt Joyce 

---
 bsp-howto/console.rst | 11 +--
 1 file changed, 1 insertion(+), 10 deletions(-)

diff --git a/bsp-howto/console.rst b/bsp-howto/console.rst
index aef13a8..1ead39e 100644
--- a/bsp-howto/console.rst
+++ b/bsp-howto/console.rst
@@ -52,16 +52,7 @@ calls such as :c:func:`printf` or :c:func:`scanf` or 
directly via the
 Build System and Files
 ==
 
-A new serial device driver should consist of three parts.
-
-- A section in the BSPs Makefile.am:
-
-.. code-block:: makefile
-
-  [...]
-  libbsp_a_SOURCES += ../../shared/dev/serial/console-termios.c
-  libbsp_a_SOURCES += console/console.c
-  [...]
+A new serial device driver should consist of two parts.
 
 - A general serial device specific low-level driver providing the handler table
   and the device context specialization for the Termios
-- 
2.35.3

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

[PATCH 0/3] bsp-howto/console: Remove obsolete references / Fix typos

[Matthew Joyce]

From: Matt Joyce 

Hello,

Please find the following edits to bsp-howto/console attached.

Thanks very much!

Sincerely,
Matt

Matt Joyce (3):
  bsp-howto/console: Remove reference to old build system
  bsp-howto/console: Remove reference to deprecated function
  bsp-howto/console: Fix typos

 bsp-howto/console.rst | 32 
 1 file changed, 8 insertions(+), 24 deletions(-)

-- 
2.35.3

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

[PATCH 3/3] bsp-howto/console: Fix typos

[Matthew Joyce]

From: Matt Joyce 

---
 bsp-howto/console.rst | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/bsp-howto/console.rst b/bsp-howto/console.rst
index 71e156d..9056e0f 100644
--- a/bsp-howto/console.rst
+++ b/bsp-howto/console.rst
@@ -236,8 +236,8 @@ character has been received or the transmitter is ready for 
another character.
 
 In the simplest case, the :c:func:`my_driver_interrupt_handler` will have to
 check the status of the serial device and determine what caused the interrupt.
-The following describes the operation of an
-:c:func:`my_driver_interrupt_handler` which has to do this:
+The following describes the operation of
+:c:func:`my_driver_interrupt_handler`:
 
 .. code-block:: c
 
@@ -279,15 +279,15 @@ The following describes the operation of an
 }
 
 The :c:func:`my_driver_interrupt_write()` handler is responsible for telling
-the device that the ``n`` characters at ``buf`` are to be transmitted.  It the
-value ``n`` is zero to indicate that no more characters are to send.  The
+the device that the ``n`` characters at ``buf`` are to be transmitted.  If the
+value ``n`` is zero, it indicates that there are no more characters to send.  
The
 driver can disable the transmit interrupts now.  This routine is invoked either
 from task context with disabled interrupts to start a new transmission process
 with exactly one character in case of an idle output state or from the
 interrupt handler to refill the transmitter.  If the routine is invoked to
-start the transmit process the output state will become busy and Termios starts
+start the transmit process, the output state will become busy and Termios 
starts
 to fill the output buffer.  If the transmit interrupt arises before Termios was
-able to fill the transmit buffer you will end up with one interrupt per
+able to fill the transmit buffer, you will end up with one interrupt per
 character.
 
 .. code-block:: c
@@ -371,7 +371,7 @@ called by Termios.  The device registered as 
:file:`/dev/console` (or
   }
 
   /*
-   * Return true to indicate a successful set attributes, and false
+   * Return true to indicate a successful first open, and false
* otherwise.
*/
   return true;
-- 
2.35.3

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

[PATCH 1/2] eng: Fix typos

[Matthew Joyce]

From: Matt Joyce 

---
 eng/prequalification.rst | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/eng/prequalification.rst b/eng/prequalification.rst
index ba1840a..0dddb15 100644
--- a/eng/prequalification.rst
+++ b/eng/prequalification.rst
@@ -15,7 +15,7 @@ standards typically do not specify software functionality but 
address
 topics like requirements definition, traceability, having a documented
 change process, coding style, testing requirements, and a user's
 manual. During system test, these standards call for a review - usually
-by an independent entity - that the standard has been adhered too. These
+by an independent entity - that the standard has been adhered to. These
 reviews cover a broad variety of topics and activities, but the process
 is generally referred to as qualification, verification, or auditing
 against the specific standard in use. The RTEMS Project will use the
@@ -83,8 +83,8 @@ Stakeholder Involvement
 
 Qualification of RTEMS is a specialized activity and only specific users
 of RTEMS will complete a formal qualification activity. The RTEMS Project
-cannot self-fund this entire activity and requires stakeholder to invest
-in an ongoing basis to ensure that any investment they make is maintained
-and viable in an ongoing basis. The RTEMS core developers view steady
+cannot self-fund this entire activity and requires stakeholders to invest
+on an ongoing basis to ensure that any investment they make is maintained
+and viable in the long-term. The RTEMS core developers view steady
 support of the qualification effort as necessary to continue to lower
 the overall costs of qualifying RTEMS.
-- 
2.35.3

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

[PATCH 2/2] c-user/clock: Fix typo

[Matthew Joyce]

From: Matt Joyce 

---
 c-user/clock/directives.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/c-user/clock/directives.rst b/c-user/clock/directives.rst
index 6e1542c..877204a 100644
--- a/c-user/clock/directives.rst
+++ b/c-user/clock/directives.rst
@@ -1222,7 +1222,7 @@ system initialization using :term:`CLOCK_MONOTONIC`.
 .. rubric:: PARAMETERS:
 
 ``uptime``
-This parameter is the pointer to a `struct timeval
+This parameter is the pointer to a `struct timespec
 
`_
 object.  When the directive call is successful, the seconds and nanoseconds
 elapsed since some time point during the system initialization and some
-- 
2.35.3

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

Re: [PATCH 1/2] bsp/stm32f4xxxx_rcc.h: Fix RCC register defines

[Matthew Joyce]

RCC_CFGR_PPRE2 is defined twice, on lines 240 and 241. Based on the 
other defines, I think 241 should have been RCC_CFGR_PPRE2_MSK. Is that 
what you're referring to? Thanks!


On 19.10.22 14:48, Joel Sherrill wrote:

I don't see the name defined twice. Are they functionally equivalent?

On Wed, Oct 19, 2022, 5:57 AM Matthew Joyce 
 wrote:


From: Matt Joyce 

Fix a double define of RCC_CFGR_PPRE2 and add RCC_CFGR_PPRE1_MSK.
---
 bsps/arm/stm32f4/include/bsp/stm32f4_rcc.h | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/bsps/arm/stm32f4/include/bsp/stm32f4_rcc.h
b/bsps/arm/stm32f4/include/bsp/stm32f4_rcc.h
index 7dadfbe756..dc4a7f0edd 100644
--- a/bsps/arm/stm32f4/include/bsp/stm32f4_rcc.h
+++ b/bsps/arm/stm32f4/include/bsp/stm32f4_rcc.h
@@ -231,6 +231,7 @@ typedef struct {
 #define RCC_CFGR_HPRE_BY_512 BSP_FLD32( 15, 4, 7 )

 #define RCC_CFGR_PPRE1 10
+#define RCC_CFGR_PPRE1_MSK BSP_MSK32( 10, 12 )
 #define RCC_CFGR_PPRE1_BY_1 0
 #define RCC_CFGR_PPRE1_BY_2 BSP_FLD32( 4, 10, 12 )
 #define RCC_CFGR_PPRE1_BY_4 BSP_FLD32( 5, 10, 12 )
@@ -238,7 +239,7 @@ typedef struct {
 #define RCC_CFGR_PPRE1_BY_16 BSP_FLD32( 7, 10, 12 )

 #define RCC_CFGR_PPRE2 13
-#define RCC_CFGR_PPRE2 BSP_MSK32( 13, 15 )
+#define RCC_CFGR_PPRE2_MSK BSP_MSK32( 13, 15 )
 #define RCC_CFGR_PPRE2_BY_1 0
 #define RCC_CFGR_PPRE2_BY_2 BSP_FLD32( 4, 13, 15 )
 #define RCC_CFGR_PPRE2_BY_4 BSP_FLD32( 5, 13, 15 )
-- 
2.31.1


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


--
embedded brains GmbH
Herr Matthew JOYCE
Dornierstr. 4
82178 Puchheim
Germany
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 2/2] bsp/stm32f4.h: Remove double define

[Matthew Joyce]

It's on line 131. Both defines are referring to the same address 
(0x40023C00) --one define just starts from STM32F4_BASE and the other 
from STM32F4_AHB1_BASE.


On 19.10.22 14:46, Joel Sherrill wrote:

Looks ok but where was the other one?

On Wed, Oct 19, 2022, 5:57 AM Matthew Joyce 
 wrote:


From: Matt Joyce 

Remove double define of STM32F4_FLASH.
---
 bsps/arm/stm32f4/include/bsp/stm32f4.h | 10 --
 1 file changed, 10 deletions(-)

diff --git a/bsps/arm/stm32f4/include/bsp/stm32f4.h
b/bsps/arm/stm32f4/include/bsp/stm32f4.h
index 7f84480ece..3b1f9ff9ba 100644
--- a/bsps/arm/stm32f4/include/bsp/stm32f4.h
+++ b/bsps/arm/stm32f4/include/bsp/stm32f4.h
@@ -54,16 +54,6 @@

 /** @} */

-/**
- * @name STM32F4 FLASH
- * @{
- */
-
-#include 
-#define STM32F4_FLASH ((volatile stm32f4_flash *) (STM32F4_BASE +
0x40023C00))
-
-/** @} */
-
 #include 

 /**
-- 
2.31.1


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


--
embedded brains GmbH
Herr Matthew JOYCE
Dornierstr. 4
82178 Puchheim
Germany
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH 0/2] bsp/stm32f4: Fix double defines

[Matthew Joyce]

From: Matt Joyce 

Fix two defines in RCC_CFGR register and remove double define of
STM32F4_FLASH.

Matt Joyce (2):
  bsp/stm32f4_rcc.h: Fix RCC register defines
  bsp/stm32f4.h: Remove double define

 bsps/arm/stm32f4/include/bsp/stm32f4.h | 10 --
 bsps/arm/stm32f4/include/bsp/stm32f4_rcc.h |  3 ++-
 2 files changed, 2 insertions(+), 11 deletions(-)

-- 
2.31.1

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

[PATCH 1/2] bsp/stm32f4xxxx_rcc.h: Fix RCC register defines

[Matthew Joyce]

From: Matt Joyce 

Fix a double define of RCC_CFGR_PPRE2 and add RCC_CFGR_PPRE1_MSK.
---
 bsps/arm/stm32f4/include/bsp/stm32f4_rcc.h | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/bsps/arm/stm32f4/include/bsp/stm32f4_rcc.h 
b/bsps/arm/stm32f4/include/bsp/stm32f4_rcc.h
index 7dadfbe756..dc4a7f0edd 100644
--- a/bsps/arm/stm32f4/include/bsp/stm32f4_rcc.h
+++ b/bsps/arm/stm32f4/include/bsp/stm32f4_rcc.h
@@ -231,6 +231,7 @@ typedef struct {
 #define RCC_CFGR_HPRE_BY_512 BSP_FLD32( 15, 4, 7 )
 
 #define RCC_CFGR_PPRE1 10
+#define RCC_CFGR_PPRE1_MSK BSP_MSK32( 10, 12 )
 #define RCC_CFGR_PPRE1_BY_1 0
 #define RCC_CFGR_PPRE1_BY_2 BSP_FLD32( 4, 10, 12 )
 #define RCC_CFGR_PPRE1_BY_4 BSP_FLD32( 5, 10, 12 )
@@ -238,7 +239,7 @@ typedef struct {
 #define RCC_CFGR_PPRE1_BY_16 BSP_FLD32( 7, 10, 12 )
 
 #define RCC_CFGR_PPRE2 13
-#define RCC_CFGR_PPRE2 BSP_MSK32( 13, 15 )
+#define RCC_CFGR_PPRE2_MSK BSP_MSK32( 13, 15 )
 #define RCC_CFGR_PPRE2_BY_1 0
 #define RCC_CFGR_PPRE2_BY_2 BSP_FLD32( 4, 13, 15 )
 #define RCC_CFGR_PPRE2_BY_4 BSP_FLD32( 5, 13, 15 )
-- 
2.31.1

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

[PATCH 2/2] bsp/stm32f4.h: Remove double define

[Matthew Joyce]

From: Matt Joyce 

Remove double define of STM32F4_FLASH.
---
 bsps/arm/stm32f4/include/bsp/stm32f4.h | 10 --
 1 file changed, 10 deletions(-)

diff --git a/bsps/arm/stm32f4/include/bsp/stm32f4.h 
b/bsps/arm/stm32f4/include/bsp/stm32f4.h
index 7f84480ece..3b1f9ff9ba 100644
--- a/bsps/arm/stm32f4/include/bsp/stm32f4.h
+++ b/bsps/arm/stm32f4/include/bsp/stm32f4.h
@@ -54,16 +54,6 @@
 
 /** @} */
 
-/**
- * @name STM32F4 FLASH
- * @{
- */
-
-#include 
-#define STM32F4_FLASH ((volatile stm32f4_flash *) (STM32F4_BASE + 0x40023C00))
-
-/** @} */
-
 #include 
 
 /**
-- 
2.31.1

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

[PATCH] bsp-howto: Specify name of clock driver init func

[Matthew Joyce]

From: Matt Joyce 

---
 bsp-howto/clock.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bsp-howto/clock.rst b/bsp-howto/clock.rst
index f3d30ce..b03f5ce 100644
--- a/bsp-howto/clock.rst
+++ b/bsp-howto/clock.rst
@@ -65,7 +65,7 @@ Clock Tick Only
 Initialization
 ==
 
-The clock driver is initialized by a dedicated system initialization handler if
+The clock driver is initialized by the ``_Clock_Initialize()`` handler if
 requested by the application configuration option
 ``CONFIGURE_APPLICATION_NEEDS_CLOCK_DRIVER``.  The clock driver does not use 
the
 legacy IO driver framework.
-- 
2.31.1

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

[PATCH v2 6/6] testsuites/libtests/malloctest: fix warnings

[Matthew Joyce]

From: Matt Joyce 

Edited tests to fix new gcc 12 warnings.

Updates #4662
---
 testsuites/libtests/malloctest/init.c | 22 +-
 1 file changed, 13 insertions(+), 9 deletions(-)

diff --git a/testsuites/libtests/malloctest/init.c 
b/testsuites/libtests/malloctest/init.c
index 05d97a27d5..ee8bd8ca52 100644
--- a/testsuites/libtests/malloctest/init.c
+++ b/testsuites/libtests/malloctest/init.c
@@ -60,8 +60,7 @@ static void test_realloc(void)
   for (i=2 ; i<2048 ; i++) {
 p2 = realloc(p1, i);
 if (p2 != p1)
-  printf( "realloc - failed grow in place: "
-  "%p != realloc(%p,%zu)\n", p1, p2, i);
+  printf( "realloc - failed grow in place\n");
 p1 = p2;
   }
   free(p1);
@@ -71,8 +70,7 @@ static void test_realloc(void)
   for (i=2047 ; i>=1; i--)  {
 p2 = realloc(p1, i);
 if (p2 != p1)
-  printf( "realloc - failed shrink in place: "
-  "%p != realloc(%p,%zu)\n", p1, p2, i);
+  printf( "realloc - failed shrink in place\n");
 p1 = p2;
   }
   free(p1);
@@ -85,7 +83,7 @@ static void test_realloc(void)
   p3 = realloc(p1, 64);
   if (p3 == p1 || p3 == NULL)
 printf(
-  "realloc - failed non-in place: realloc(%p,%d) = %p\n", p1, 64, p3);
+  "realloc - failed non-in place\n");
   free(p3);
   free(p2);
 
@@ -120,11 +118,17 @@ static void test_realloc(void)
   _Thread_Dispatch_enable( _Per_CPU_Get() );
 
   /*
-   *  Realloc with a bad pointer to force a point
+   *  Realloc with a pointer that is not in the heap.
+   *  The error should be detected and NULL should be returned.
*/
+#pragma GCC diagnostic push
+#pragma GCC diagnostic ignored "-Wfree-nonheap-object"
   p4 = realloc( test_realloc, 32 );
-
+  rtems_test_assert(p4 == NULL);
+#pragma GCC diagnostic pop
   p4 = _realloc_r( NULL, NULL, 1 );
+  rtems_test_assert(p4 != NULL);
+  free(p4);
 }
 
 #define TEST_HEAP_SIZE 2048
@@ -1528,8 +1532,8 @@ static void test_early_malloc( void )
 
   free( q );
 
-  r = realloc( q, 128 );
-  rtems_test_assert( r == q );
+  r = realloc( NULL, 128 );
+  rtems_test_assert( r != NULL );
 
   s = malloc( 1 );
   rtems_test_assert( s != NULL );
-- 
2.31.1

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

[PATCH v2 5/6] testsuites/libtests/POSIX/free.c: fix warning

[Matthew Joyce]

From: Matt Joyce 

This change fixes a new warning in gcc 12.

Updates #4662
---
 testsuites/libtests/POSIX/free.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/testsuites/libtests/POSIX/free.c b/testsuites/libtests/POSIX/free.c
index 8550eaa85c..6bc961b968 100644
--- a/testsuites/libtests/POSIX/free.c
+++ b/testsuites/libtests/POSIX/free.c
@@ -14,7 +14,7 @@
 
 int main (void)
 {
-  free((void *) 42);
+  free(NULL);
 
   return 0;
 }
-- 
2.31.1

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

[PATCH v2 3/6] cpukit/libcsupport/src/__gettod.c: avoid warning

[Matthew Joyce]

From: Matt Joyce 

Define _LIBC to ensure access to the function prototype.
The purpose is to avoid a new warning in gcc 12.

Updates #4662.
---
 cpukit/libcsupport/src/__gettod.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/cpukit/libcsupport/src/__gettod.c 
b/cpukit/libcsupport/src/__gettod.c
index 610f2c4d4a..e2a7ba6e64 100644
--- a/cpukit/libcsupport/src/__gettod.c
+++ b/cpukit/libcsupport/src/__gettod.c
@@ -39,9 +39,11 @@
 
 #if defined(RTEMS_NEWLIB)
 /*
- *  Needed to get the prototype for the newlib helper method
+ *  Needed to get the prototype for the newlib helper method. Which define
+ *  is required depends on the version of newlib.
  */
 #define _COMPILING_NEWLIB
+#define _LIBC
 
 #include 
 #include 
-- 
2.31.1

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

[PATCH v2 4/6] cpukit/libmd/md5.c: fix warning

[Matthew Joyce]

From: Matt Joyce 

Specify array size in parameter to match function prototype. This
fixes a new warning in gcc 12.

Updates #4662
---
 cpukit/libmd/md5.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/cpukit/libmd/md5.c b/cpukit/libmd/md5.c
index 4c909f37a0..5e3a100c7b 100644
--- a/cpukit/libmd/md5.c
+++ b/cpukit/libmd/md5.c
@@ -165,7 +165,7 @@ void MD5Update (
ends with the desired message digest in mdContext->digest[0...15].
  */
 void MD5Final (
-  unsigned char hash[],
+  unsigned char hash[16],
   MD5_CTX *mdContext )
 {
   UINT4 in[16];
-- 
2.31.1

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

[PATCH v2 2/6] cpukit/posix/src/_execve.c: fix warning

[Matthew Joyce]

From: Matt Joyce 

Define _LIBC to access prototype for _execve() function. This fixes a
new warning in gcc 12.

Updates #4662
---
 cpukit/posix/src/_execve.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/cpukit/posix/src/_execve.c b/cpukit/posix/src/_execve.c
index 2858d13082..f1b9d9d3a1 100644
--- a/cpukit/posix/src/_execve.c
+++ b/cpukit/posix/src/_execve.c
@@ -43,9 +43,11 @@
 #endif
 
 /*
- *  Needed to get the prototype for this newlib helper method
+ *  Needed to get the prototype for this newlib helper method. Which define
+ *  is required depends on the version of newlib.
  */
 #define _COMPILING_NEWLIB
+#define _LIBC
 
 #include 
 #include 
-- 
2.31.1

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

[PATCH v2 1/6] libcsupport/src/__times.c: fix warning

[Matthew Joyce]

From: Matt Joyce 

Define _LIBC to access prototype for _times() function. This fixes a
new warning in gcc 12.

Updates #4662.
---
 cpukit/libcsupport/src/__times.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/cpukit/libcsupport/src/__times.c b/cpukit/libcsupport/src/__times.c
index 629a7bc633..6fcf3f8501 100644
--- a/cpukit/libcsupport/src/__times.c
+++ b/cpukit/libcsupport/src/__times.c
@@ -38,9 +38,11 @@
 #endif
 
 /*
- *  Needed to get the prototype for this newlib helper method
+ *  Needed to get the prototype for this newlib helper method. Which define
+ *  is required depends on the version of newlib.
  */
 #define _COMPILING_NEWLIB
+#define _LIBC
 
 #include 
 
-- 
2.31.1

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

[PATCH v2 0/6] gcc 12 warning fixes

[Matthew Joyce]

From: Matt Joyce 

Hello,

Please find v2 attached.

Changes:
1) Added additional patch for __gettod.c
2) Edited comments / formatting
3) Edited tests in malloctest
4) References RTEMS ticket #4662

Thank you!

Sincerely,

Matt

Matt Joyce (6):
  libcsupport/src/__times.c: fix warning
  cpukit/posix/src/_execve.c: fix warning
  cpukit/libcsupport/src/__gettod.c: avoid warning
  cpukit/libmd/md5.c: fix warning
  testsuites/libtests/POSIX/free.c: fix warning
  testsuites/libtests/malloctest: fix warnings

 cpukit/libcsupport/src/__gettod.c |  4 +++-
 cpukit/libcsupport/src/__times.c  |  4 +++-
 cpukit/libmd/md5.c|  2 +-
 cpukit/posix/src/_execve.c|  4 +++-
 testsuites/libtests/POSIX/free.c  |  2 +-
 testsuites/libtests/malloctest/init.c | 22 +-
 6 files changed, 24 insertions(+), 14 deletions(-)

-- 
2.31.1

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

[PATCH 3/5] cpukit/libmd/md5.c: fix warning

[Matthew Joyce]

From: Matt Joyce 

Specify array size in parameter to match function prototype. This
fixes a new warning in gcc 12.
---
 cpukit/libmd/md5.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/cpukit/libmd/md5.c b/cpukit/libmd/md5.c
index 4c909f37a0..5e3a100c7b 100644
--- a/cpukit/libmd/md5.c
+++ b/cpukit/libmd/md5.c
@@ -165,7 +165,7 @@ void MD5Update (
ends with the desired message digest in mdContext->digest[0...15].
  */
 void MD5Final (
-  unsigned char hash[],
+  unsigned char hash[16],
   MD5_CTX *mdContext )
 {
   UINT4 in[16];
-- 
2.31.1

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

[PATCH 4/5] testsuites/libtests/POSIX/free.c: fix warning

[Matthew Joyce]

From: Matt Joyce 

This change fixes a new warning in gcc 12.
---
 testsuites/libtests/POSIX/free.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/testsuites/libtests/POSIX/free.c b/testsuites/libtests/POSIX/free.c
index 8550eaa85c..6bc961b968 100644
--- a/testsuites/libtests/POSIX/free.c
+++ b/testsuites/libtests/POSIX/free.c
@@ -14,7 +14,7 @@
 
 int main (void)
 {
-  free((void *) 42);
+  free(NULL);
 
   return 0;
 }
-- 
2.31.1

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

[PATCH 5/5] testsuites/libtests/malloctest: fix warning

[Matthew Joyce]

From: Matt Joyce 

Removed problematic free() and several unnecessary print statement
parameters. This fixes new warnings in gcc 12.
---
 testsuites/libtests/malloctest/init.c | 17 +++--
 1 file changed, 3 insertions(+), 14 deletions(-)

diff --git a/testsuites/libtests/malloctest/init.c 
b/testsuites/libtests/malloctest/init.c
index 05d97a27d5..bf623f9cbe 100644
--- a/testsuites/libtests/malloctest/init.c
+++ b/testsuites/libtests/malloctest/init.c
@@ -60,8 +60,7 @@ static void test_realloc(void)
   for (i=2 ; i<2048 ; i++) {
 p2 = realloc(p1, i);
 if (p2 != p1)
-  printf( "realloc - failed grow in place: "
-  "%p != realloc(%p,%zu)\n", p1, p2, i);
+  printf( "realloc - failed grow in place");
 p1 = p2;
   }
   free(p1);
@@ -71,8 +70,7 @@ static void test_realloc(void)
   for (i=2047 ; i>=1; i--)  {
 p2 = realloc(p1, i);
 if (p2 != p1)
-  printf( "realloc - failed shrink in place: "
-  "%p != realloc(%p,%zu)\n", p1, p2, i);
+  printf( "realloc - failed shrink in place");
 p1 = p2;
   }
   free(p1);
@@ -85,7 +83,7 @@ static void test_realloc(void)
   p3 = realloc(p1, 64);
   if (p3 == p1 || p3 == NULL)
 printf(
-  "realloc - failed non-in place: realloc(%p,%d) = %p\n", p1, 64, p3);
+  "realloc - failed non-in place");
   free(p3);
   free(p2);
 
@@ -118,13 +116,6 @@ static void test_realloc(void)
   malloc_walk_ok = malloc_walk( 1234, false );
   rtems_test_assert( malloc_walk_ok );
   _Thread_Dispatch_enable( _Per_CPU_Get() );
-
-  /*
-   *  Realloc with a bad pointer to force a point
-   */
-  p4 = realloc( test_realloc, 32 );
-
-  p4 = _realloc_r( NULL, NULL, 1 );
 }
 
 #define TEST_HEAP_SIZE 2048
@@ -1526,8 +1517,6 @@ static void test_early_malloc( void )
   rtems_test_assert( p != q );
   rtems_test_assert( q[0] == 0 );
 
-  free( q );
-
   r = realloc( q, 128 );
   rtems_test_assert( r == q );
 
-- 
2.31.1

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

[PATCH 1/5] libcsupport/src/__times.c: fix warning

[Matthew Joyce]

From: Matt Joyce 

Define _LIBC to access prototype for _times() function. This fixes a
new warning in gcc 12.
---
 cpukit/libcsupport/src/__times.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/cpukit/libcsupport/src/__times.c b/cpukit/libcsupport/src/__times.c
index 629a7bc633..1a994ad953 100644
--- a/cpukit/libcsupport/src/__times.c
+++ b/cpukit/libcsupport/src/__times.c
@@ -42,6 +42,11 @@
  */
 #define _COMPILING_NEWLIB
 
+/*
+ *  Needed to get the prototype for _times()
+ */
+#define _LIBC
+
 #include 
 
 #include 
-- 
2.31.1

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

[PATCH 0/5] Fix gcc 12 warnings

[Matthew Joyce]

From: Matt Joyce 

Hello,

These patches fix several new warnings which appeared with
gcc 12.

Sincerely,

Matt

Matt Joyce (5):
  libcsupport/src/__times.c: fix warning
  cpukit/posix/src/_execve.c: fix warning
  cpukit/libmd/md5.c: fix warning
  testsuites/libtests/POSIX/free.c: fix warning
  testsuites/libtests/malloctest: fix warning

 cpukit/libcsupport/src/__times.c  |  5 +
 cpukit/libmd/md5.c|  2 +-
 cpukit/posix/src/_execve.c|  5 +
 testsuites/libtests/POSIX/free.c  |  2 +-
 testsuites/libtests/malloctest/init.c | 17 +++--
 5 files changed, 15 insertions(+), 16 deletions(-)

-- 
2.31.1

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

[PATCH 2/5] cpukit/posix/src/_execve.c: fix warning

[Matthew Joyce]

From: Matt Joyce 

Define _LIBC to access prototype for _execve() function. This fixes a
new warning in gcc 12.
---
 cpukit/posix/src/_execve.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/cpukit/posix/src/_execve.c b/cpukit/posix/src/_execve.c
index 2858d13082..29c4fe8fcf 100644
--- a/cpukit/posix/src/_execve.c
+++ b/cpukit/posix/src/_execve.c
@@ -47,6 +47,11 @@
  */
 #define _COMPILING_NEWLIB
 
+/*
+ *  Needed to get the prototype for _execve()
+ */
+#define _LIBC
+
 #include 
 #include 
 #include 
-- 
2.31.1

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

[PATCH 0/1] Newlib01: Add tests for rand() and lrand48()

[Matthew Joyce]

From: Matt Joyce 

Hello,

This patch adds tests for rand() and lrand48(). It checks to ensure their state
is thread-specific, that they are properly initialized, and return the expected
sequence for default seed values.

Sincerely,

Matt

Matt Joyce (1):
  Newlib01: Add tests for rand() and lrand48()

 testsuites/libtests/newlib01/init.c   | 50 +++
 testsuites/libtests/newlib01/newlib01.doc |  3 ++
 2 files changed, 53 insertions(+)

-- 
2.31.1

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

[PATCH 1/1] Newlib01: Add tests for rand() and lrand48()

[Matthew Joyce]

From: Matt Joyce 

Check that the state of rand() and lrand48() is thread-specific,
that they are properly initialized, and return the expected
sequence of pseudo-random numbers for default seed values.
---
 testsuites/libtests/newlib01/init.c   | 50 +++
 testsuites/libtests/newlib01/newlib01.doc |  3 ++
 2 files changed, 53 insertions(+)

diff --git a/testsuites/libtests/newlib01/init.c 
b/testsuites/libtests/newlib01/init.c
index 8975a72fad..0bb3c4628b 100644
--- a/testsuites/libtests/newlib01/init.c
+++ b/testsuites/libtests/newlib01/init.c
@@ -82,6 +82,50 @@ static void wait(void)
   rtems_test_assert(sc == RTEMS_SUCCESSFUL);
 }
 
+/*
+ * Check that rand() is properly initialized and returns the expected sequence
+ * for default seed values. A call to rand() without any previous call to
+ * srand() generates the same sequence as when srand() is first called with a
+ * seed value of 1.
+ */
+static void test_rand(void)
+{
+  int rv;
+
+  rv = rand();
+  rtems_test_assert(rv == 1481765933);
+  rv = rand();
+  rtems_test_assert(rv == 1085377743);
+  rv = rand();
+  rtems_test_assert(rv == 1270216262);
+
+  srand(1);
+  rv = rand();
+  rtems_test_assert(rv == 1481765933);
+  rv = rand();
+  rtems_test_assert(rv == 1085377743);
+  rv = rand();
+  rtems_test_assert(rv == 1270216262);
+}
+
+/*
+ * Check that lrand48() is properly initialized and returns the expected
+ * sequence for default seed values. A call to lrand48() without any previous
+ * call to srand48() uses default constant initializer values set in the _seed
+ * member of struct _rand48.
+ */
+static void test_lrand48(void)
+{
+  long rv;
+
+  rv = lrand48();
+  rtems_test_assert(rv == 851401618);
+  rv = lrand48();
+  rtems_test_assert(rv == 1804928587);
+  rv = lrand48();
+  rtems_test_assert(rv == 758783491);
+}
+
 static void stdio_file_worker(rtems_task_argument arg)
 {
   test_context *ctx = _instance;
@@ -90,6 +134,9 @@ static void stdio_file_worker(rtems_task_argument arg)
   char buf[1] = { 'x' };
   size_t n;
 
+  test_rand();
+  test_lrand48();
+
   rtems_test_assert(reent->__cleanup == NULL);
 
   output = stdout = fopen(_file_path[0], "r+");
@@ -454,6 +501,9 @@ static void Init(rtems_task_argument arg)
   int rv;
 
   TEST_BEGIN();
+  test_rand();
+  test_lrand48();
+
   ctx->main_task_id = rtems_task_self();
 
   /* Fill dynamic file pool in Newlib */
diff --git a/testsuites/libtests/newlib01/newlib01.doc 
b/testsuites/libtests/newlib01/newlib01.doc
index fbda12aa98..dc16584418 100644
--- a/testsuites/libtests/newlib01/newlib01.doc
+++ b/testsuites/libtests/newlib01/newlib01.doc
@@ -19,3 +19,6 @@ concepts:
   - Check that exit procedures provide proper resource cleanup. Ensure that
 a file opened from a worker task--but that is not assigned to a stdio
 stream--is not closed during thread termination.
+  - Check that the state of random number generators is thread-specific, they
+are properly initialized, and return the expected sequence for default
+seed values.
-- 
2.31.1

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

[PATCH] hexdump-conv.c: Fix gcc 12 compiler warning

[Matthew Joyce]

From: Matt Joyce 

Fixed newly generated compiler warning introduced in the switch to gcc 12.
gcc 12 adds the new warning -Warray-compare, which warns agains potentially
dubious comparisons between operands of array type.
---
 cpukit/libmisc/shell/hexdump-conv.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/cpukit/libmisc/shell/hexdump-conv.c 
b/cpukit/libmisc/shell/hexdump-conv.c
index aa16f9b169..0dee76a595 100644
--- a/cpukit/libmisc/shell/hexdump-conv.c
+++ b/cpukit/libmisc/shell/hexdump-conv.c
@@ -117,7 +117,7 @@ retry:
if (clen == 0)
clen = 1;
else if (clen == (size_t)-1 || (clen == (size_t)-2 &&
-   buf == peekbuf)) {
+   [0] == [0])) {
memset(>mbstate, 0, sizeof(pr->mbstate));
wc = *p;
clen = 1;
-- 
2.31.1

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

Re: [PATCH v2 1/1] newlib01: Check exit procs for global FILE obj

[Matthew Joyce]

Hi Dr. Joel,

I just sent an update which addresses these issues.

Thanks!

Sincerely,

Matt

On 28.03.22 23:13, Joel Sherrill wrote:
I don't see anything obviously wrong but I don't have any idea what 
the test is actually trying to exercise.


How about some comments and is there a doc file in this test directory 
that needs updating?


--joel

On Mon, Mar 28, 2022 at 4:04 AM Matthew Joyce 
 wrote:


From: Matt Joyce 

---
 testsuites/libtests/newlib01/init.c | 110
++--
 1 file changed, 88 insertions(+), 22 deletions(-)

diff --git a/testsuites/libtests/newlib01/init.c
b/testsuites/libtests/newlib01/init.c
index c58154023b..bba187e8e2 100644
--- a/testsuites/libtests/newlib01/init.c
+++ b/testsuites/libtests/newlib01/init.c
@@ -28,6 +28,8 @@ const char rtems_test_name[] = "NEWLIB 1";

 static const char file_path[] = "/file";

+static const char file_path2[] = "/file2";
+
 typedef enum {
   INIT,
   OPEN,
@@ -39,6 +41,8 @@ typedef struct {
   rtems_id main_task_id;
   rtems_id worker_task_id;
   test_state current;
+  FILE *glob_file_stream;
+  int glob_fd;
 } test_context;

 static test_context test_instance;
@@ -59,7 +63,7 @@ static void wait(void)
   rtems_test_assert(sc == RTEMS_SUCCESSFUL);
 }

-static void worker_task(rtems_task_argument arg)
+static void thread_specific_worker(rtems_task_argument arg)
 {
   test_context *ctx = _instance;
   struct _reent *reent = _REENT;
@@ -90,6 +94,30 @@ static void worker_task(rtems_task_argument arg)
   rtems_test_assert(0);
 }

+static void global_file_object_worker(rtems_task_argument arg)
+{
+  test_context *ctx = _instance;
+  FILE *fp;
+  char buf[1] = { 'y' };
+  size_t n;
+  int fd;
+
+  fp = ctx->glob_file_stream = fopen(_path2[0], "w");
+  rtems_test_assert(fp != NULL);
+
+  /* Get file descriptor of new global file stream, store it in
text context */
+  fd = fileno(fp);
+  rtems_test_assert(fd != -1);
+  ctx->glob_fd = fd;
+
+  n = fwrite([0], sizeof(buf), 1, fp);
+  rtems_test_assert(n == 1);
+
+  wake_up_main(ctx);
+
+  rtems_test_assert(0);
+}
+
 static int handler_open(
   rtems_libio_t *iop,
   const char *path,
@@ -250,9 +278,34 @@ static const IMFS_node_control node_control =
IMFS_GENERIC_INITIALIZER(
   IMFS_node_destroy_default
 );

-static void test_thread_specific_close(test_context *ctx)
+static void task_create_and_delete_helper(
+  test_context *ctx,
+  rtems_task_entry entry
+)
 {
   rtems_status_code sc;
+
+  sc = rtems_task_create(
+  rtems_build_name('W', 'O', 'R', 'K'),
+  2,
+  RTEMS_MINIMUM_STACK_SIZE,
+  RTEMS_DEFAULT_MODES,
+  RTEMS_DEFAULT_ATTRIBUTES,
+  >worker_task_id
+  );
+  rtems_test_assert(sc == RTEMS_SUCCESSFUL);
+
+  sc = rtems_task_start(ctx->worker_task_id, entry, 0);
+  rtems_test_assert(sc == RTEMS_SUCCESSFUL);
+
+  wait();
+
+  sc = rtems_task_delete(ctx->worker_task_id);
+  rtems_test_assert(sc == RTEMS_SUCCESSFUL);
+}
+
+static void test_thread_specific_close(test_context *ctx)
+{
   int rv;
   rtems_resource_snapshot snapshot;

@@ -266,23 +319,7 @@ static void
test_thread_specific_close(test_context *ctx)
   );
   rtems_test_assert(rv == 0);

-  sc = rtems_task_create(
-    rtems_build_name('W', 'O', 'R', 'K'),
-    2,
-    RTEMS_MINIMUM_STACK_SIZE,
-    RTEMS_DEFAULT_MODES,
-    RTEMS_DEFAULT_ATTRIBUTES,
-    >worker_task_id
-  );
-  rtems_test_assert(sc == RTEMS_SUCCESSFUL);
-
-  sc = rtems_task_start(ctx->worker_task_id, worker_task, 0);
-  rtems_test_assert(sc == RTEMS_SUCCESSFUL);
-
-  wait();
-
-  sc = rtems_task_delete(ctx->worker_task_id);
-  rtems_test_assert(sc == RTEMS_SUCCESSFUL);
+  task_create_and_delete_helper(ctx, thread_specific_worker);

   rv = unlink(_path[0]);
   rtems_test_assert(rv == 0);
@@ -290,6 +327,11 @@ static void
test_thread_specific_close(test_context *ctx)
 rtems_test_assert(rtems_resource_snapshot_check());
 }

+static void test_global_file_object_close(test_context *ctx)
+{
+  task_create_and_delete_helper(ctx, global_file_object_worker);
+}
+
 /*
  * This exit handler will be called last among the functions
registered with
  * atexit(). Check that stdio file descriptors are closed. The
Newlib cleanup
@@ -298,6 +340,7 @@ static void
test_thread_specific_close(test_context *ctx)
  */
 static void check_after_libio_exit(void)
 {
+  test_context *ctx = _instance;
   struct stat unused;
   int rv;

[PATCH v3 1/1] newlib01: Added tests for exit procedures

[Matthew Joyce]

From: Matt Joyce 

Added tests for exit procedures to ensure proper resource
cleanup. The test now checks cleanup for files assigned
to stdio streams and non-stdio streams.
---
 testsuites/libtests/newlib01/init.c   | 120 +-
 testsuites/libtests/newlib01/newlib01.doc |   5 +-
 2 files changed, 101 insertions(+), 24 deletions(-)

diff --git a/testsuites/libtests/newlib01/init.c 
b/testsuites/libtests/newlib01/init.c
index c58154023b..40d2f683b0 100644
--- a/testsuites/libtests/newlib01/init.c
+++ b/testsuites/libtests/newlib01/init.c
@@ -28,6 +28,8 @@ const char rtems_test_name[] = "NEWLIB 1";
 
 static const char file_path[] = "/file";
 
+static const char file_path2[] = "/file2";
+
 typedef enum {
   INIT,
   OPEN,
@@ -39,6 +41,8 @@ typedef struct {
   rtems_id main_task_id;
   rtems_id worker_task_id;
   test_state current;
+  FILE *glob_file_stream;
+  int glob_fd;
 } test_context;
 
 static test_context test_instance;
@@ -59,7 +63,7 @@ static void wait(void)
   rtems_test_assert(sc == RTEMS_SUCCESSFUL);
 }
 
-static void worker_task(rtems_task_argument arg)
+static void stdio_file_worker(rtems_task_argument arg)
 {
   test_context *ctx = _instance;
   struct _reent *reent = _REENT;
@@ -90,6 +94,30 @@ static void worker_task(rtems_task_argument arg)
   rtems_test_assert(0);
 }
 
+static void non_stdio_file_worker(rtems_task_argument arg)
+{
+  test_context *ctx = _instance;
+  FILE *fp;
+  char buf[1] = { 'y' };
+  size_t n;
+  int fd;
+
+  fp = ctx->glob_file_stream = fopen(_path2[0], "w");
+  rtems_test_assert(fp != NULL);
+
+  /* Get file descriptor of new global file stream, store it in text context */
+  fd = fileno(fp);
+  rtems_test_assert(fd != -1);
+  ctx->glob_fd = fd;
+
+  n = fwrite([0], sizeof(buf), 1, fp);
+  rtems_test_assert(n == 1);
+
+  wake_up_main(ctx);
+
+  rtems_test_assert(0);
+}
+
 static int handler_open(
   rtems_libio_t *iop,
   const char *path,
@@ -250,9 +278,38 @@ static const IMFS_node_control node_control = 
IMFS_GENERIC_INITIALIZER(
   IMFS_node_destroy_default
 );
 
-static void test_thread_specific_close(test_context *ctx)
+static void task_create_and_delete_helper(
+  test_context *ctx,
+  rtems_task_entry entry
+)
 {
   rtems_status_code sc;
+
+  sc = rtems_task_create(
+  rtems_build_name('W', 'O', 'R', 'K'),
+  2,
+  RTEMS_MINIMUM_STACK_SIZE,
+  RTEMS_DEFAULT_MODES,
+  RTEMS_DEFAULT_ATTRIBUTES,
+  >worker_task_id
+  );
+  rtems_test_assert(sc == RTEMS_SUCCESSFUL);
+
+  sc = rtems_task_start(ctx->worker_task_id, entry, 0);
+  rtems_test_assert(sc == RTEMS_SUCCESSFUL);
+
+  wait();
+
+  sc = rtems_task_delete(ctx->worker_task_id);
+  rtems_test_assert(sc == RTEMS_SUCCESSFUL);
+}
+
+/*
+ * Check that a FILE opened by a task and assigned to a stdio stream is closed
+ * during thread termination. Ensure that resources are returned to the system.
+ */
+static void test_stdio_file(test_context *ctx)
+{
   int rv;
   rtems_resource_snapshot snapshot;
 
@@ -266,23 +323,7 @@ static void test_thread_specific_close(test_context *ctx)
   );
   rtems_test_assert(rv == 0);
 
-  sc = rtems_task_create(
-rtems_build_name('W', 'O', 'R', 'K'),
-2,
-RTEMS_MINIMUM_STACK_SIZE,
-RTEMS_DEFAULT_MODES,
-RTEMS_DEFAULT_ATTRIBUTES,
->worker_task_id
-  );
-  rtems_test_assert(sc == RTEMS_SUCCESSFUL);
-
-  sc = rtems_task_start(ctx->worker_task_id, worker_task, 0);
-  rtems_test_assert(sc == RTEMS_SUCCESSFUL);
-
-  wait();
-
-  sc = rtems_task_delete(ctx->worker_task_id);
-  rtems_test_assert(sc == RTEMS_SUCCESSFUL);
+  task_create_and_delete_helper(ctx, stdio_file_worker);
 
   rv = unlink(_path[0]);
   rtems_test_assert(rv == 0);
@@ -290,6 +331,15 @@ static void test_thread_specific_close(test_context *ctx)
   rtems_test_assert(rtems_resource_snapshot_check());
 }
 
+/*
+ * Open a global FILE object from a task but do not assign it to a stdio
+ * stream. The FILE is not closed upon thread termination.
+ */
+static void test_non_stdio_file(test_context *ctx)
+{
+  task_create_and_delete_helper(ctx, non_stdio_file_worker);
+}
+
 /*
  * This exit handler will be called last among the functions registered with
  * atexit(). Check that stdio file descriptors are closed. The Newlib cleanup
@@ -298,6 +348,7 @@ static void test_thread_specific_close(test_context *ctx)
  */
 static void check_after_libio_exit(void)
 {
+  test_context *ctx = _instance;
   struct stat unused;
   int rv;
 
@@ -319,6 +370,11 @@ static void check_after_libio_exit(void)
   rtems_test_assert(stdin->_flags != 0);
   rtems_test_assert(stdout->_flags != 0);
   rtems_test_assert(stderr->_flags != 0);
+
+  /* Global file tests. Global fd still open at this point. */
+  rv = fstat(ctx->glob_fd, );
+  rtems_test_assert(rv == 0);
+  rtems_test_assert(ctx->glob_file_stream->_flags != 0);
 }
 
 static void register_exit_handler_before_libio_exit(void)
@@ -342,7 +398,7 @@ RTEMS_SYSINIT_ITEM(register_exit_handler_before_libio_exit,
  * cleanup procedures have been called. Therefore, stdio 

[PATCH v3 0/1] newlib01: Added tests for exit procedures

[Matthew Joyce]

From: Matt Joyce 

Version 3 adds comments for clarification and updates the doc file.

Matt Joyce (1):
  newlib01: Added tests for exit procedures

 testsuites/libtests/newlib01/init.c   | 120 +-
 testsuites/libtests/newlib01/newlib01.doc |   5 +-
 2 files changed, 101 insertions(+), 24 deletions(-)

-- 
2.31.1

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

[PATCH v2 1/1] newlib01: Check exit procs for global FILE obj

[Matthew Joyce]

From: Matt Joyce 

---
 testsuites/libtests/newlib01/init.c | 110 ++--
 1 file changed, 88 insertions(+), 22 deletions(-)

diff --git a/testsuites/libtests/newlib01/init.c 
b/testsuites/libtests/newlib01/init.c
index c58154023b..bba187e8e2 100644
--- a/testsuites/libtests/newlib01/init.c
+++ b/testsuites/libtests/newlib01/init.c
@@ -28,6 +28,8 @@ const char rtems_test_name[] = "NEWLIB 1";
 
 static const char file_path[] = "/file";
 
+static const char file_path2[] = "/file2";
+
 typedef enum {
   INIT,
   OPEN,
@@ -39,6 +41,8 @@ typedef struct {
   rtems_id main_task_id;
   rtems_id worker_task_id;
   test_state current;
+  FILE *glob_file_stream;
+  int glob_fd;
 } test_context;
 
 static test_context test_instance;
@@ -59,7 +63,7 @@ static void wait(void)
   rtems_test_assert(sc == RTEMS_SUCCESSFUL);
 }
 
-static void worker_task(rtems_task_argument arg)
+static void thread_specific_worker(rtems_task_argument arg)
 {
   test_context *ctx = _instance;
   struct _reent *reent = _REENT;
@@ -90,6 +94,30 @@ static void worker_task(rtems_task_argument arg)
   rtems_test_assert(0);
 }
 
+static void global_file_object_worker(rtems_task_argument arg)
+{
+  test_context *ctx = _instance;
+  FILE *fp;
+  char buf[1] = { 'y' };
+  size_t n;
+  int fd;
+
+  fp = ctx->glob_file_stream = fopen(_path2[0], "w");
+  rtems_test_assert(fp != NULL);
+
+  /* Get file descriptor of new global file stream, store it in text context */
+  fd = fileno(fp);
+  rtems_test_assert(fd != -1);
+  ctx->glob_fd = fd;
+
+  n = fwrite([0], sizeof(buf), 1, fp);
+  rtems_test_assert(n == 1);
+
+  wake_up_main(ctx);
+
+  rtems_test_assert(0);
+}
+
 static int handler_open(
   rtems_libio_t *iop,
   const char *path,
@@ -250,9 +278,34 @@ static const IMFS_node_control node_control = 
IMFS_GENERIC_INITIALIZER(
   IMFS_node_destroy_default
 );
 
-static void test_thread_specific_close(test_context *ctx)
+static void task_create_and_delete_helper(
+  test_context *ctx,
+  rtems_task_entry entry
+)
 {
   rtems_status_code sc;
+
+  sc = rtems_task_create(
+  rtems_build_name('W', 'O', 'R', 'K'),
+  2,
+  RTEMS_MINIMUM_STACK_SIZE,
+  RTEMS_DEFAULT_MODES,
+  RTEMS_DEFAULT_ATTRIBUTES,
+  >worker_task_id
+  );
+  rtems_test_assert(sc == RTEMS_SUCCESSFUL);
+
+  sc = rtems_task_start(ctx->worker_task_id, entry, 0);
+  rtems_test_assert(sc == RTEMS_SUCCESSFUL);
+
+  wait();
+
+  sc = rtems_task_delete(ctx->worker_task_id);
+  rtems_test_assert(sc == RTEMS_SUCCESSFUL);
+}
+
+static void test_thread_specific_close(test_context *ctx)
+{
   int rv;
   rtems_resource_snapshot snapshot;
 
@@ -266,23 +319,7 @@ static void test_thread_specific_close(test_context *ctx)
   );
   rtems_test_assert(rv == 0);
 
-  sc = rtems_task_create(
-rtems_build_name('W', 'O', 'R', 'K'),
-2,
-RTEMS_MINIMUM_STACK_SIZE,
-RTEMS_DEFAULT_MODES,
-RTEMS_DEFAULT_ATTRIBUTES,
->worker_task_id
-  );
-  rtems_test_assert(sc == RTEMS_SUCCESSFUL);
-
-  sc = rtems_task_start(ctx->worker_task_id, worker_task, 0);
-  rtems_test_assert(sc == RTEMS_SUCCESSFUL);
-
-  wait();
-
-  sc = rtems_task_delete(ctx->worker_task_id);
-  rtems_test_assert(sc == RTEMS_SUCCESSFUL);
+  task_create_and_delete_helper(ctx, thread_specific_worker);
 
   rv = unlink(_path[0]);
   rtems_test_assert(rv == 0);
@@ -290,6 +327,11 @@ static void test_thread_specific_close(test_context *ctx)
   rtems_test_assert(rtems_resource_snapshot_check());
 }
 
+static void test_global_file_object_close(test_context *ctx)
+{
+  task_create_and_delete_helper(ctx, global_file_object_worker);
+}
+
 /*
  * This exit handler will be called last among the functions registered with
  * atexit(). Check that stdio file descriptors are closed. The Newlib cleanup
@@ -298,6 +340,7 @@ static void test_thread_specific_close(test_context *ctx)
  */
 static void check_after_libio_exit(void)
 {
+  test_context *ctx = _instance;
   struct stat unused;
   int rv;
 
@@ -319,6 +362,11 @@ static void check_after_libio_exit(void)
   rtems_test_assert(stdin->_flags != 0);
   rtems_test_assert(stdout->_flags != 0);
   rtems_test_assert(stderr->_flags != 0);
+
+  /* Global file tests. Global fd still open at this point. */
+  rv = fstat(ctx->glob_fd, );
+  rtems_test_assert(rv == 0);
+  rtems_test_assert(ctx->glob_file_stream->_flags != 0);
 }
 
 static void register_exit_handler_before_libio_exit(void)
@@ -342,7 +390,7 @@ RTEMS_SYSINIT_ITEM(register_exit_handler_before_libio_exit,
  * cleanup procedures have been called. Therefore, stdio file descriptors
  * should be open and stdio FILE object flags should be non-zero.
  */
-static void test_exit_handling(void)
+static void test_exit_handling(test_context *ctx)
 {
   struct stat unused;
   int rv;
@@ -360,6 +408,14 @@ static void test_exit_handling(void)
   rtems_test_assert(stdout->_flags != 0);
   rtems_test_assert(stderr->_flags != 0);
 
+  /*
+   * Global file descriptor should still be open; global FILE object flags
+   * should still be non-zero.
+   */

[PATCH v2 0/1] newlib01: Check exit procs for global FILE obj

[Matthew Joyce]

From: Matt Joyce 

v2 removes some duplicate code and unnecessary asserts.

Matt Joyce (1):
  newlib01: Added test of exit procedures for global FILE object

 testsuites/libtests/newlib01/init.c | 110 ++--
 1 file changed, 88 insertions(+), 22 deletions(-)

-- 
2.31.1

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

[PATCH 0/1] newlib01: Test exit procs for global FILE object

[Matthew Joyce]

From: Matt Joyce 

This patch adds additional testing to newlib01, checking exit
procedures for global FILE objects.

Matt Joyce (1):
  newlib01: Added test of exit procedures for global FILE object

 testsuites/libtests/newlib01/init.c | 102 ++--
 1 file changed, 96 insertions(+), 6 deletions(-)

-- 
2.31.1

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

[PATCH 1/1] newlib01: Test exit procs for global FILE object

[Matthew Joyce]

From: Matt Joyce 

---
 testsuites/libtests/newlib01/init.c | 102 ++--
 1 file changed, 96 insertions(+), 6 deletions(-)

diff --git a/testsuites/libtests/newlib01/init.c 
b/testsuites/libtests/newlib01/init.c
index c58154023b..c20e0a04ff 100644
--- a/testsuites/libtests/newlib01/init.c
+++ b/testsuites/libtests/newlib01/init.c
@@ -28,6 +28,8 @@ const char rtems_test_name[] = "NEWLIB 1";
 
 static const char file_path[] = "/file";
 
+static const char file_path2[] = "/file2";
+
 typedef enum {
   INIT,
   OPEN,
@@ -39,6 +41,8 @@ typedef struct {
   rtems_id main_task_id;
   rtems_id worker_task_id;
   test_state current;
+  FILE *glob_file_stream;
+  int glob_fd;
 } test_context;
 
 static test_context test_instance;
@@ -59,7 +63,7 @@ static void wait(void)
   rtems_test_assert(sc == RTEMS_SUCCESSFUL);
 }
 
-static void worker_task(rtems_task_argument arg)
+static void worker_task1(rtems_task_argument arg)
 {
   test_context *ctx = _instance;
   struct _reent *reent = _REENT;
@@ -90,6 +94,41 @@ static void worker_task(rtems_task_argument arg)
   rtems_test_assert(0);
 }
 
+static void worker_task2(rtems_task_argument arg)
+{
+  test_context *ctx = _instance;
+  struct _reent *reent = _REENT;
+  FILE *fp;
+  char buf[1] = { 'y' };
+  size_t n;
+  int fd;
+
+  rtems_test_assert(reent->__cleanup == NULL);
+
+  fp = ctx->glob_file_stream = fopen(_path2[0], "w");
+  rtems_test_assert(fp != NULL);
+
+  /*
+   * Check newlib's __sinit does not touch our assigned file pointer.
+   */
+  rtems_test_assert(reent->__cleanup == NULL);
+  rtems_test_assert(fflush(fp) == 0);
+  rtems_test_assert(reent->__cleanup != NULL);
+  rtems_test_assert(ctx->glob_file_stream == fp);
+
+  /* Get file descriptor of new global file stream, store it in text context */
+  fd = fileno(fp);
+  rtems_test_assert(fd != -1);
+  ctx->glob_fd = fd;
+
+  n = fwrite([0], sizeof(buf), 1, fp);
+  rtems_test_assert(n == 1);
+
+  wake_up_main(ctx);
+
+  rtems_test_assert(0);
+}
+
 static int handler_open(
   rtems_libio_t *iop,
   const char *path,
@@ -267,7 +306,7 @@ static void test_thread_specific_close(test_context *ctx)
   rtems_test_assert(rv == 0);
 
   sc = rtems_task_create(
-rtems_build_name('W', 'O', 'R', 'K'),
+rtems_build_name('W', 'R', 'K', '1'),
 2,
 RTEMS_MINIMUM_STACK_SIZE,
 RTEMS_DEFAULT_MODES,
@@ -276,7 +315,7 @@ static void test_thread_specific_close(test_context *ctx)
   );
   rtems_test_assert(sc == RTEMS_SUCCESSFUL);
 
-  sc = rtems_task_start(ctx->worker_task_id, worker_task, 0);
+  sc = rtems_task_start(ctx->worker_task_id, worker_task1, 0);
   rtems_test_assert(sc == RTEMS_SUCCESSFUL);
 
   wait();
@@ -290,6 +329,33 @@ static void test_thread_specific_close(test_context *ctx)
   rtems_test_assert(rtems_resource_snapshot_check());
 }
 
+static void test_global_file_object_close(test_context *ctx)
+{
+  int rv;
+  rtems_status_code sc;
+
+  sc = rtems_task_create(
+  rtems_build_name('W', 'R', 'K', '2'),
+  2,
+  RTEMS_MINIMUM_STACK_SIZE,
+  RTEMS_DEFAULT_MODES,
+  RTEMS_DEFAULT_ATTRIBUTES,
+  >worker_task_id
+  );
+  rtems_test_assert(sc == RTEMS_SUCCESSFUL);
+
+  sc = rtems_task_start(ctx->worker_task_id, worker_task2, 0);
+  rtems_test_assert(sc == RTEMS_SUCCESSFUL);
+
+  wait();
+
+  sc = rtems_task_delete(ctx->worker_task_id);
+  rtems_test_assert(sc == RTEMS_SUCCESSFUL);
+
+  rv = unlink(_path2[0]);
+  rtems_test_assert(rv == 0);
+}
+
 /*
  * This exit handler will be called last among the functions registered with
  * atexit(). Check that stdio file descriptors are closed. The Newlib cleanup
@@ -298,6 +364,7 @@ static void test_thread_specific_close(test_context *ctx)
  */
 static void check_after_libio_exit(void)
 {
+  test_context *ctx = _instance;
   struct stat unused;
   int rv;
 
@@ -319,6 +386,11 @@ static void check_after_libio_exit(void)
   rtems_test_assert(stdin->_flags != 0);
   rtems_test_assert(stdout->_flags != 0);
   rtems_test_assert(stderr->_flags != 0);
+
+  /* Global file tests. Global fd still open at this point. */
+  rv = fstat(ctx->glob_fd, );
+  rtems_test_assert(rv == 0);
+  rtems_test_assert(ctx->glob_file_stream->_flags != 0);
 }
 
 static void register_exit_handler_before_libio_exit(void)
@@ -342,7 +414,7 @@ RTEMS_SYSINIT_ITEM(register_exit_handler_before_libio_exit,
  * cleanup procedures have been called. Therefore, stdio file descriptors
  * should be open and stdio FILE object flags should be non-zero.
  */
-static void test_exit_handling(void)
+static void test_exit_handling(test_context *ctx)
 {
   struct stat unused;
   int rv;
@@ -360,6 +432,14 @@ static void test_exit_handling(void)
   rtems_test_assert(stdout->_flags != 0);
   rtems_test_assert(stderr->_flags != 0);
 
+  /*
+   * Global file descriptor should still be open; global FILE object flags
+   * should still be non-zero.
+   */
+  rv = fstat(ctx->glob_fd, );
+  rtems_test_assert(rv == 0);
+  rtems_test_assert(ctx->glob_file_stream->_flags != 0);
+
   /* Run exit handlers and 

[PATCH 1/1] newlib01: Check exit processing for file objects

[Matthew Joyce]

From: Matt Joyce 

---
 testsuites/libtests/newlib01/init.c | 131 ++--
 1 file changed, 124 insertions(+), 7 deletions(-)

diff --git a/testsuites/libtests/newlib01/init.c 
b/testsuites/libtests/newlib01/init.c
index 5864047a80..58757a7676 100644
--- a/testsuites/libtests/newlib01/init.c
+++ b/testsuites/libtests/newlib01/init.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 2014 embedded brains GmbH.  All rights reserved.
+ * Copyright (c) 2014, 2022 embedded brains GmbH.  All rights reserved.
  *
  * The license and distribution terms for this file may be
  * found in the file LICENSE in this distribution or at
@@ -11,13 +11,16 @@
 #endif
 
 #include 
+#include 
 
 #include 
+#include 
 
 #include 
 #include 
 #include 
 #include 
+#include 
 
 #include "tmacros.h"
 
@@ -25,6 +28,15 @@ const char rtems_test_name[] = "NEWLIB 1";
 
 static const char file_path[] = "/file";
 
+static void test_sysinit_handler1(void);
+
+/*
+ * Test Newlib exit procedures. Allows us to place an exit handler at position
+ * 0, which is called after rtems_stdio_exit by Newlib's __call_exitprocs().
+ */
+RTEMS_SYSINIT_ITEM( test_sysinit_handler1, RTEMS_SYSINIT_STD_FILE_DESCRIPTORS,
+   RTEMS_SYSINIT_ORDER_FIRST );
+
 typedef enum {
   INIT,
   OPEN,
@@ -247,7 +259,45 @@ static const IMFS_node_control node_control = 
IMFS_GENERIC_INITIALIZER(
   IMFS_node_destroy_default
 );
 
-static void test(void)
+/*
+ * This exit handler will be called last among the functions registered with
+ * _atexit. Check that stdio file descriptors are closed. The cleanup handler
+ * has not yet run, so the stdio file objects themselves are still open.
+ */
+static void test_exit_handler1(void)
+{
+  struct stat buffer;
+  int status;
+
+  status = fstat(0, );
+  rtems_test_assert(status == -1);
+  rtems_test_assert(errno == EBADF);
+
+  status = fstat(1, );
+  rtems_test_assert(status == -1);
+  rtems_test_assert(errno == EBADF);
+
+  status = fstat(2, );
+  rtems_test_assert(status == -1);
+  rtems_test_assert(errno == EBADF);
+
+  rtems_test_assert( stdin->_flags != 0 );
+  rtems_test_assert( stdout->_flags != 0 );
+  rtems_test_assert( stderr->_flags != 0 );
+}
+
+/*
+ * Register test_exit_handler1 at position 0 in the _atexit _fns array.
+ * Thus, test_exit_handler1 will be called last--after rtems_libio_exit().
+ */
+static void test_sysinit_handler1(void)
+{
+  int rv;
+  rv = atexit(test_exit_handler1);
+  rtems_test_assert(rv == 0);
+}
+
+static void test_thread_specific_close(void)
 {
   test_context *ctx = _instance;
   rtems_status_code sc;
@@ -297,14 +347,79 @@ static void test(void)
   rtems_test_assert(rtems_resource_snapshot_check());
 }
 
+/*
+ * At this point, neither the _atexit functions nor __cleanup have been
+ * called. Therefore, stdio file descriptors should be open and stdio file
+ * object flags should be non-zero.
+ */
+static void test_exit_handling(void)
+{
+  struct stat buffer;
+  int status;
+
+  status = fstat(0, );
+  rtems_test_assert(status == 0);
+  rtems_test_assert(errno == 0);
+
+  status = fstat(1, );
+  rtems_test_assert(status == 0);
+  rtems_test_assert(errno == 0);
+
+  status = fstat(2, );
+  rtems_test_assert(status == 0);
+  rtems_test_assert(errno == 0);
+
+  rtems_test_assert( stdin->_flags != 0 );
+  rtems_test_assert( stdout->_flags != 0 );
+  rtems_test_assert( stderr->_flags != 0 );
+
+  /* Run exit handlers and __cleanup */
+  exit(0);
+}
+
 static void Init(rtems_task_argument arg)
 {
   TEST_BEGIN();
+  test_thread_specific_close();
+  test_exit_handling();
+}
 
-  test();
-
-  TEST_END();
-  rtems_test_exit(0);
+static void fatal_extension(
+  rtems_fatal_source source,
+  bool always_set_to_false,
+  rtems_fatal_code error
+)
+{
+  if (
+source == RTEMS_FATAL_SOURCE_EXIT
+  && !always_set_to_false
+  && error == 0
+  ) {
+
+/*
+ * Final conditions check after exit handlers and __cleanup have run.
+ * File descriptors and file objects themselves are closed.
+ */
+struct stat buffer;
+int status;
+
+status = fstat(0, );
+rtems_test_assert(status == -1);
+rtems_test_assert(errno == EBADF);
+
+status = fstat(1, );
+rtems_test_assert(status == -1);
+rtems_test_assert(errno == EBADF);
+
+status = fstat(2, );
+rtems_test_assert(status == -1);
+rtems_test_assert(errno == EBADF);
+
+rtems_test_assert( stdin->_flags == 0 );
+rtems_test_assert( stdout->_flags == 0 );
+rtems_test_assert( stderr->_flags == 0 );
+TEST_END();
+  }
 }
 
 #define CONFIGURE_APPLICATION_NEEDS_CLOCK_DRIVER
@@ -314,7 +429,9 @@ static void Init(rtems_task_argument arg)
 
 #define CONFIGURE_MAXIMUM_TASKS 2
 
-#define CONFIGURE_INITIAL_EXTENSIONS RTEMS_TEST_INITIAL_EXTENSION
+#define CONFIGURE_INITIAL_EXTENSIONS \
+  { .fatal = fatal_extension }, \
+  RTEMS_TEST_INITIAL_EXTENSION
 
 #define CONFIGURE_RTEMS_INIT_TASKS_TABLE
 
-- 
2.31.1

___
devel mailing list
devel@rtems.org

[PATCH 0/1] newlib01: Check exit processing for file objects

[Matthew Joyce]

From: Matt Joyce 

This patch adds additional tests for Newlib's exit processing for
file objects.

Matt Joyce (1):
  newlib01: Check exit processing for file objects

 testsuites/libtests/newlib01/init.c | 131 ++--
 1 file changed, 124 insertions(+), 7 deletions(-)

-- 
2.31.1

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

[PATCH 1/1] libtests/newlib01: Edit assert statements to check initialization

[Matthew Joyce]

From: Matt Joyce 

Edit assert statements in worker thread to check initialization
against the __cleanup member of struct _reent instead of sdidinit.
This will allow the removal of sdidinit in a follow up Newlib
patch.
---
 testsuites/libtests/newlib01/init.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/testsuites/libtests/newlib01/init.c 
b/testsuites/libtests/newlib01/init.c
index 383abf41f6..adea8d84ca 100644
--- a/testsuites/libtests/newlib01/init.c
+++ b/testsuites/libtests/newlib01/init.c
@@ -70,7 +70,7 @@ static void worker_task(rtems_task_argument arg)
   char buf[1] = { 'x' };
   size_t n;
 
-  rtems_test_assert(reent->__sdidinit == 0);
+  rtems_test_assert(reent->__cleanup == 0);
 
   output = stdout = fopen(_path[0], "r+");
   rtems_test_assert(stdout != NULL);
@@ -78,9 +78,9 @@ static void worker_task(rtems_task_argument arg)
   /*
* Check newlib's __sinit does not touch our assigned file pointer.
*/
-  rtems_test_assert(reent->__sdidinit == 0);
+  rtems_test_assert(reent->__cleanup == 0);
   rtems_test_assert(fflush(stdout) == 0);
-  rtems_test_assert(reent->__sdidinit != 0);
+  rtems_test_assert(reent->__cleanup != 0);
   rtems_test_assert(stdout == output);
 
   n = fwrite([0], sizeof(buf), 1, stdout);
-- 
2.31.1

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

[PATCH 0/1] libtests/newlib01: Edit assert statements to check initialization

[Matthew Joyce]

From: Matt Joyce 

Edit assert statements to check initialization against __cleanup
member of Newlib's struct _reent instead of __sdidinit. This will
allow the removal of __sdidinit in a follow up Newlib patch.

Matt Joyce (1):
  libtests/newlib01: Edit assert statements to check initialization

 testsuites/libtests/newlib01/init.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

-- 
2.31.1

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

Re: Interested in working on ticket #2902, #4328, or #4334

[Matthew Joyce]

Hi Prateek,

>From the new methods that were added to the latest draft version of the
POSIX standard back around April, you might want to look at posix_getdents,
sem_clockwait, and ppoll. Those ones are still waiting to be added.

My blog post here (
https://mfjoyce2004.medium.com/adding-posix-apis-to-newlib-testing-with-rtems-280975508fb7)
hopefully might help you a little bit as you get started.

Take care and reach out if you have any questions!

Sincerely,

Matt

On Thu, Nov 11, 2021 at 7:06 PM Joel Sherrill  wrote:

> On Thu, Nov 11, 2021 at 10:34 AM Prateek Pardeshi
>  wrote:
> >
> > Hello Everyone,
> >
> > I doubt that my email went into spam. Sorry for the inconvenience.
>
> I have no idea. I know I have been swamped with work and personal matters.
>
> > Email link:
> > https://lists.rtems.org/pipermail/devel/2021-November/069853.html
> >
> > From now on, I'll be using *Gmail* for sending emails on this list.
>
> Mostly it is a matter of using text format. Some clients do not do well
> with threaded discussions also.
>
> And now for the tickets:
>
> #2902 - Microblaze port
>
> I just closed this. The Microblaze port was recently merged. It has a
> BSP for HW and Qemu. Network support for libbsd and lwip should be
> close. libdl and libdebugger support are missing. libdl should be
> approachable.
>
> #4328 - New POSIX APIs from Issue 8 (2021/2022)
>
> Matthew Joyce worked on this list for GSoC 2021. I've cc'ed him for
> suggestions on which APIs make sense to tackle next.
>
> #4334 - Replace Mongoose with Civetweb
>
> Is still an open project.  I'm not sure whether we would ultimately
> want a "cloned and owned" snapshot of civitweb or if it would make
> more sense to have an RSB package which could build it.
>
> It would be a change from the current usage pattern to have it
> from RSB, but that is likely the better long term solution.
>
> --joel
>
> > Thanking you,
> > Prateek
> > ___
> > 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 1/1] Implementation / tests for pthread_cond_clockwait()

[Matthew Joyce]

On Wed, Aug 18, 2021 at 8:44 PM Joel Sherrill  wrote:
>
> On Wed, Aug 18, 2021 at 6:17 AM Matt Joyce  wrote:
> >
> > Added implementation of the pthread_cond_clockwait()
> > method to cpukit/posix/src/condclockwait.c. Additional
> > logic added to condwaitsupp.c to implement new method.
> > pthread_cond_clockwait() has been added to the Issue 8
> > POSIX Standard.
> >
> > psx17 test added to testsuites/psxtests to test the
> > newly added method.
> > ---
> >  cpukit/include/rtems/posix/condimpl.h |   1 +
> >  cpukit/posix/src/condclockwait.c  |  69 +++
> >  cpukit/posix/src/condtimedwait.c  |   1 +
> >  cpukit/posix/src/condwait.c   |   1 +
> >  cpukit/posix/src/condwaitsupp.c   |  64 ++-
> >  spec/build/testsuites/psxtests/grp.yml|   2 +
> >  spec/build/testsuites/psxtests/psx17.yml  |  20 +
> >  testsuites/psxtests/Makefile.am   |   8 +
> >  testsuites/psxtests/configure.ac  |   1 +
> >  testsuites/psxtests/psx17/init.c  | 425 ++
> >  testsuites/psxtests/psx17/psx17.doc   |  45 ++
> >  testsuites/psxtests/psx17/psx17.scn   |  82 
> >  testsuites/psxtests/psx17/system.h|  57 +++
> >  .../psxhdrs/pthread/pthread_cond_clockwait.c  |   2 +-
> >  14 files changed, 761 insertions(+), 17 deletions(-)
> >  create mode 100644 cpukit/posix/src/condclockwait.c
> >  create mode 100644 spec/build/testsuites/psxtests/psx17.yml
> >  create mode 100644 testsuites/psxtests/psx17/init.c
> >  create mode 100644 testsuites/psxtests/psx17/psx17.doc
> >  create mode 100644 testsuites/psxtests/psx17/psx17.scn
> >  create mode 100644 testsuites/psxtests/psx17/system.h
> >
> > diff --git a/cpukit/include/rtems/posix/condimpl.h 
> > b/cpukit/include/rtems/posix/condimpl.h
> > index 66e09bf6d8..6efbc3af70 100644
> > --- a/cpukit/include/rtems/posix/condimpl.h
> > +++ b/cpukit/include/rtems/posix/condimpl.h
> > @@ -152,6 +152,7 @@ int _POSIX_Condition_variables_Signal_support(
> >  int _POSIX_Condition_variables_Wait_support(
> >pthread_cond_t*cond,
> >pthread_mutex_t   *mutex,
> > +  clockid_t clock_id,
> >const struct timespec *abstime
>
> The clock_id parameter should be aligned with the rest.
I'm having a little trouble with this and the one below: It looks
aligned in both vscode and in vim...even when I cat the patch. But
here it's clearly misaligned.
I went back in and re-aligned all the variables, but I'm still getting
this misaligned output. Could you please advise?
>
> >  );
> >
> > diff --git a/cpukit/posix/src/condclockwait.c 
> > b/cpukit/posix/src/condclockwait.c
> > new file mode 100644
> > index 00..4104235706
> > --- /dev/null
> > +++ b/cpukit/posix/src/condclockwait.c
> > @@ -0,0 +1,69 @@
> > +/**
> > + * @file
> > + *
> > + * @ingroup POSIXAPI
> > + *
> > + * @brief Waiting on a Condition
> > + */
> > +
> > +/*
> > +* Copyright (C) 2021 Matthew Joyce
>
> General question. Do we have a master list Matthew needs to be added to?
> Or is that just documentation?
>
> > +*
> > +* 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 SOFTW

Re: [PATCH 1/1] libc: Added prototypes for new POSIX APIs

[Matthew Joyce]

Thanks very much for the quick reply! Ok, I'll make that change and submit.

Sincerely,

Matt

On Fri, Aug 6, 2021 at 3:52 PM Joel Sherrill  wrote:
>
> On Fri, Aug 6, 2021 at 8:37 AM Matt Joyce  wrote:
> >
> > Added function prototypes to newlib/libc/include/pthread.h
> > for the following Issue 8 Standard APIs:
> > pthread_cond_clockwait()
> > pthread_mutex_clocklock()
> > pthread_rwlock_clockrdlock()
> > pthread_rwlock_clockwrlock()
> > ---
> >  newlib/libc/include/pthread.h | 31 +++
> >  1 file changed, 31 insertions(+)
> >
> > diff --git a/newlib/libc/include/pthread.h b/newlib/libc/include/pthread.h
> > index c9d24d6e0..77cb0ed74 100644
> > --- a/newlib/libc/include/pthread.h
> > +++ b/newlib/libc/include/pthread.h
> > @@ -87,6 +87,15 @@ int  pthread_mutex_timedlock (pthread_mutex_t *__mutex,
> >
> >  #endif /* _POSIX_TIMEOUTS */
> >
> > +/* Using __MISC_VISIBLE until POSIX Issue 8 is officially released */
> > +#if __MISC_VISIBLE
> > +
> > +/* The Issue 8 standard adds pthread_mutex_clocklock() */
> > +int pthread_mutex_clocklock(pthread_mutex_t *__restrict, clockid_t,
> > +  const struct timespec *__restrict);
> > +
> > +#endif /* __MISC_VISIBLE */
> > +
>
> I don't know that you need white space after the #if and before the #endif
> in newlib headers.
>
> With that change, I'd say it is ready to submit.
>
> >  /* Condition Variable Initialization Attributes, P1003.1c/Draft 10, p. 96 
> > */
> >
> >  intpthread_condattr_init (pthread_condattr_t *__attr);
> > @@ -126,6 +135,16 @@ intpthread_cond_wait (pthread_cond_t *__cond, 
> > pthread_mutex_t *__mutex);
> >  intpthread_cond_timedwait (pthread_cond_t *__cond,
> > pthread_mutex_t *__mutex,
> > const struct timespec *__abstime);
> > +
> > +/* Using __MISC_VISIBLE until POSIX Issue 8 is officially released */
> > +#if __MISC_VISIBLE
> > +
> > +/* The Issue 8 standard adds pthread_cond_clockwait() */
> > +int pthread_cond_clockwait(pthread_cond_t *__restrict,
> > +   pthread_mutex_t *__restrict, clockid_t,
> > +  const struct timespec *__restrict);
> > +
> > +#endif /* __MISC_VISIBLE */
> >
> >  #if defined(_POSIX_THREAD_PRIORITY_SCHEDULING)
> >
> > @@ -423,6 +442,18 @@ intpthread_rwlock_trywrlock (pthread_rwlock_t 
> > *__rwlock);
> >  intpthread_rwlock_timedwrlock (pthread_rwlock_t *__rwlock,
> > const struct timespec *__abstime);
> >
> > +/* Using __MISC_VISIBLE until POSIX Issue 8 is officially released */
> > +#if __MISC_VISIBLE
> > +
> > +/* The Issue 8 standard adds pthread_rwlock_clockrdlock()
> > +*  and pthread_rwlock_clockwrlock()*/
> > +int pthread_rwlock_clockrdlock(pthread_rwlock_t *__restrict, clockid_t,
> > +  const struct timespec *__restrict);
> > +int pthread_rwlock_clockwrlock(pthread_rwlock_t *__restrict, clockid_t,
> > +  const struct timespec *__restrict);
> > +
> > +#endif /* __MISC_VISIBLE */
> > +
> >  #endif /* defined(_POSIX_READER_WRITER_LOCKS) */
> >
> >
> > --
> > 2.31.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 1/2] libc: Added implementations for sig2str/str2sig

[Matthew Joyce]

On Wed, Jul 7, 2021 at 4:04 PM Joel Sherrill  wrote:
>
> On Wed, Jul 7, 2021 at 5:46 AM Matt Joyce  wrote:
> >
> > Added function implementations for sig2str() and str2sig() in libc/signal 
> > in order
> > to improve POSIX compliance.
> > ---
> >  newlib/libc/signal/sig2str.c | 156 +++
> >  1 file changed, 156 insertions(+)
> >  create mode 100644 newlib/libc/signal/sig2str.c
> >
> > diff --git a/newlib/libc/signal/sig2str.c b/newlib/libc/signal/sig2str.c
> > new file mode 100644
> > index 0..a07fa2a38
> > --- /dev/null
> > +++ b/newlib/libc/signal/sig2str.c
> > @@ -0,0 +1,156 @@
> > +/* Placeholder  */
>
> Why placeholder? Seems like an odd comment.

I need to include a license / header block here...I think I should use our most
current RTEMS block, but I wanted to check to make sure!

> > +//#define __GNU_VISIBLE // defining it to have access to SIG2STR_MAX
> > +
> > +#include 
> > +#include 
> > +#include 
> > +
> > +typedef struct sig_name_and_num {
> > +  const char *sig_name;
> > +  const int  sig_num;
> > +} sig_name_and_num;
> > +
> > +static sig_name_and_num sig_array[] = {
>
> This is also const.
>
Got it, thanks!

> > +#ifdef EXIT
> > +{ "EXIT", 0 },
> > +#endif
>
> I don't think this should be included. And I don't know where you saw it.

It was in the Solaris implementation...I'll take it out!

>
> > +#ifdef SIGHUP
> > +{ "HUP", SIGHUP},
> > +#endif
>
> Indent the middle line (include the ifdef)
>
> > +#ifdef SIGINT
> > +{ "INT", SIGINT },
> > +#endif
> > +#ifdef SIGQUIT
> > +{ "QUIT", SIGQUIT },
> > +#endif
> > +#ifdef SIGILL
> > +{ "ILL", SIGILL },
> > +#endif
> > +#ifdef SIGTRAP
> > +{ "TRAP", SIGTRAP },
> > +#endif
> > +#ifdef SIGABRT
> > +{ "ABRT", SIGABRT },
> > +#endif
> > +#ifdef SIGIOT
> > +{ "IOT", SIGIOT},
> > +#endif
> > +#ifdef SIGEMT
> > +{ "EMT", SIGEMT },
> > +#endif
> > +#ifdef SIGFPE
> > +{ "FPE", SIGFPE },
> > +#endif
> > +#ifdef SIGKILL
> > +{ "KILL", SIGKILL },
> > +#endif
> > +#ifdef SIGBUS
> > +{ "BUS", SIGBUS },
> > +#endif
> > +#ifdef SIGSEGV
> > +{ "SEGV", SIGSEGV },
> > +#endif
> > +#ifdef SIGSYS
> > +{ "SYS", SIGSYS },
> > +#endif
> > +#ifdef SIGPIPE
> > +{ "PIPE", SIGPIPE },
> > +#endif
> > +#ifdef SIGALRM
> > +{ "ALRM", SIGALRM },
> > +#endif
> > +#ifdef SIGTERM
> > +{ "TERM", SIGTERM },
> > +#endif
> > +#ifdef SIGURG
> > +{ "URG", SIGURG },
> > +#endif
> > +#ifdef SIGSTOP
> > +{ "STOP", SIGSTOP },
> > +#endif
> > +#ifdef SIGTSTP
> > +{ "TSTP", SIGTSTP },
> > +#endif
> > +#ifdef SIGCONT
> > +{ "CONT", SIGCONT },
> > +#endif
> > +#ifdef SIGCHLD
> > +{ "CHLD", SIGCHLD },
> > +#endif
> > +#ifdef SIGCLD
> > +{ "CLD", SIGCLD },
> > +#endif
> > +#ifdef SIGTTIN
> > +{ "TTIN", SIGTTIN },
> > +#endif
> > +#ifdef SIGTTOU
> > +{ "TTOU", SIGTTOU },
> > +#endif
> > +#ifdef SIGIO
> > +{ "IO", SIGIO },
> > +#endif
> > +#ifdef SIGPOLL
> > +{ "POLL", SIGPOLL },
> > +#endif
> > +#ifdef SIGWINCH
> > +{ "WINCH", SIGWINCH },
> > +#endif
> > +#ifdef SIGUSR1
> > +{ "USR1", SIGUSR1 },
> > +#endif
> > +#ifdef SIGUSR2
> > +{ "USR2", SIGUSR2 },
> > +#endif
> > +// #ifdef SIGRTMIN
> > +// { "RTMIN", SIGRTMIN },
> > +// #endif
> > +// #ifdef SIGRTMAX
> > +// { "RTMAX", SIGRTMAX },
> > +// #endif
> > +#ifdef SIGPWR
> > +{ "PWR", SIGPWR },
> > +#endif
> > +#ifdef SIGXCPU
> > +{ "XCPU", SIGXCPU },
> > +#endif
> > +#ifdef SIGXFSZ
> > +{ "XFSZ", SIGXFSZ },
> > +#endif
> > +#ifdef SIGVTALRM
> > +{ "VTALRM", SIGVTALRM },
> > +#endif
> > +#ifdef SIGPROF
> > +{ "PROF", SIGPROF },
> > +#endif
> > +#ifdef SIGLOST
> > +{ "LOST", SIGLOST }
> > +#endif
> > +};
> > +
>
> Is this the entire set used across all newlib signal.h files?

I've double checked and to my knowledge it has each one from signal.h
and sys/signal.h.
It does not contain __SIGFIRSTNOTRT and __SIGLASTNOTRT. I hesitated to include
those two because in sys/signal.h they were in an #ifdef and mapped to
the values of HUP
and SIGUSR2 respectively. I thought it would not make sense (in the
way I understood it)
to have them in that way, not knowing what would be defined.

Thinking about it, if they should be included, I could keep the former
as HUP, and define the
latter as (SIGRTMIN - 1), correct?

>
> > +#define NUM_OF_SIGS (sizeof(sig_array) / sizeof(sig_name_and_num))
> > +
> > +int
> > +sig2str(int signum, char *str)
> > +{
> > +
> > +  for (sig_name_and_num *i = sig_array; i < _array[NUM_OF_SIGS]; i++){
>
> Declare the variable at the top of the function. I am not sure newlib
> has gone to assuming
> a new enough version of C for this to work on all 

Re: [PATCH] libc: Added sig2str/str2sig prototypes

[Matthew Joyce]

Dr. Joel,

Thanks, I will make these changes and resubmit!

Sincerely,

Matt

On Wed, Jul 7, 2021 at 3:57 PM Joel Sherrill  wrote:
>
> On Wed, Jul 7, 2021 at 5:46 AM Matt Joyce  wrote:
> >
> > Added definition of SIG2STR_MAX and function prototypes for sig2str
> > and str2sig in sys/signal.h in order to improve POSIX compliance.
> > ---
> >  newlib/libc/include/sys/signal.h | 12 
> >  1 file changed, 12 insertions(+)
> >
> > diff --git a/newlib/libc/include/sys/signal.h 
> > b/newlib/libc/include/sys/signal.h
> > index 45cc0366c..36dcbdb1a 100644
> > --- a/newlib/libc/include/sys/signal.h
> > +++ b/newlib/libc/include/sys/signal.h
> > @@ -238,6 +238,18 @@ int sigqueue (pid_t, int, const union sigval);
> >
> >  #endif /* __POSIX_VISIBLE >= 199309 */
> >
> > +#if __GNU_VISIBLE
>
> This is OK for now. When Issue 8 is published, this may need to change.
>
> > +
> > +/* 202x_d2-POSIX-Issue-8, p. 327 adds SIG2STR_MAX ps. 332 adds sig2str()
> > + * and str2sig() */
>
> Do not reference page number in a draft that is not widely
> distributed. How about:
>
> POSIX Issue 8 adds sig2str() and str2sig()
>
> > +
> > +#define SIG2STR_MAX sizeof("Unknown signal 4294967295 ")
>
> We both saw the email requesting the sizeof this string as the max length
> but a comment that this allows for the maximum length signal name and
> longest integer format is probably needed.
>
> > +
> > +int sig2str(int, char *);
> > +int str2sig(const char *__restrict, int *__restrict);
> > +
> > +#endif /* __GNU_VISIBLE */
> > +
> >  #if defined(___AM29K__)
> >  /* These all need to be defined for ANSI C, but I don't think they are
> > meaningful.  */
> > --
> > 2.31.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: GSOC: Adding all generated changes in patch to RSB?

[Matthew Joyce]

> Once it's set, If I'm not rebuilding the toolset, I'd guess I go
> straight to steps 2.5, 2.6 in the quick-start guide?

I'm sorry, I should have been more specific...I meant 2.5 (Build a
BSP) and 2.6 (Test a BSP) from the RTEMS quick-start?

Thanks again!

On Tue, Jun 29, 2021 at 7:21 PM Joel Sherrill  wrote:
>
> On Tue, Jun 29, 2021 at 11:55 AM Matthew Joyce  wrote:
> >
> > Dr. Joel,
> >
> > Thanks! This made me re-read your discord workflow advice from last
> > week, and it brings me to another question...You wrote:
> >
> > "You don't have to rebuild the entire toolsuite at this point. Just
> > add a functional test for sig2str.c to the testsuite (e.g. psxsigNN or
> > similar based on existing names). You have your implementation in your
> > local newlib patches."
> >
> > I did add the test, but I don't quite understand "you have your
> > implementation in your local newlib patches." Do you mean the
> > sig2str.c patch plus generated files? Where exactly is it supposed to
> > be?
>
> Yes. Your changes to newlib are captured in 1+ changes to hand-written
> source files and 1 patch to hold the generated files that really needed to
> change.
>
> > Am I following the instructions Vaibhav lays out minus the toolset
> > rebuilding? (patch in rtems/rsb/patches, calculate sha512, edit .cfg
> > used by .bset file?)
> >
>
> Yes. You only modified newlib and that's all that needs rebuilding
> until the RSB hashes change. You do not need to build binutils, gcc,
> gdb, and the other libraries every time.
>
> Plus using the RSB method, you are rebuilding newlib from scratch
> every time.
>
> Sometimes you will need to do a clean build but for the most part
> while editing a file in newlib that has been added to the Makefile.am,
> stuff regenerated, and a clean first "j-newlib" build with that, you can
> just do make/make install.
>
> > Once it's set, If I'm not rebuilding the toolset, I'd guess I go
> > straight to steps 2.5, 2.6 in the quick-start guide?
>
> I don't know his step numbers but probably.
>
> The key is to be aware of when you need to build newlib from
> scratch and when you need to address the RSB.
>
> --joel
>
> > Thank you again for your help!
> >
> > Sincerely,
> >
> > Matt
> >
> > On Tue, Jun 29, 2021 at 3:45 PM Joel Sherrill  wrote:
> > >
> > > On Tue, Jun 29, 2021 at 8:07 AM Matthew Joyce  
> > > wrote:
> > > >
> > > > Dear Mentors,
> > > >
> > > > I've implemented my new functions locally in Newlib, created basic
> > > > tests in RTEMS, now I want to add the patches to the RSB to test them.
> > > >
> > > > I think I understand that once I submit these patches to newlib, they
> > > > should only include the added lines of source code...not any changes
> > > > generated through the build process.
> > >
> > > +1
> > >
> > > > However, when I make a patch to add to RSB and test, I need to include
> > > > everything, right? There are probably about 100 modified files from
> > > > the reconf / build. Should I:
> > > > 1) "git add --all" to add the whole load of new files and changes
> > > > 2) make the commit
> > > > 3) git format patch
> > >
> > > Yes -- the RSB patch must include the generated files. But this patch set
> > > and RSB modifications are only for your use. Before RTEMS.org RSB is
> > > updated, the patch must be in the upstream newlib and we will just bump
> > > the newlib hash. That's why I suggested just building newlib (j-newlib, 
> > > make,
> > > make install, etc) locally without the RSB and testing that way.
> > >
> > > With that said, there are a couple of things to do here:
> > >
> > > + Do NOT put generated files in your main patch. Make them a separate
> > > patch in the set so they are easy to ignore.
> > >
> > > + Reverse the generated changes to anything that shouldn't change based
> > > on what you touched. These are just due to autoconf version difference. 
> > > In your
> > > case, I think this means you only need signal/Makefile.in. The rest are
> > > unneeded.
> > >
> > > + Only submit the patches with manual changes for review. Submit to devel@
> > > and when it passes review, it goes to newlib.
> > >
> > > When the work is merged into newlib, you can update the RSB newlib hash
> > > and submit your tests to RTEMS. You will have to track the status of
> > > outstanding work and continue on to the next thing while the review 
> > > process
> > > moves along.
> > >
> > > FWIW Eshan ended up tracking patches for a few months after last year's
> > > GSoC ended before we cleared his queue up.
> > >
> > > --joel
> > >
> > > >
> > > > Just want to make sure I'm understanding this point...
> > > >
> > > > Thank you!
> > > >
> > > > Sincerely,
> > > >
> > > > Matt
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSOC: Adding all generated changes in patch to RSB?

[Matthew Joyce]

Dr. Joel,

Thanks! This made me re-read your discord workflow advice from last
week, and it brings me to another question...You wrote:

"You don't have to rebuild the entire toolsuite at this point. Just
add a functional test for sig2str.c to the testsuite (e.g. psxsigNN or
similar based on existing names). You have your implementation in your
local newlib patches."

I did add the test, but I don't quite understand "you have your
implementation in your local newlib patches." Do you mean the
sig2str.c patch plus generated files? Where exactly is it supposed to
be? Am I following the instructions Vaibhav lays out minus the toolset
rebuilding? (patch in rtems/rsb/patches, calculate sha512, edit .cfg
used by .bset file?)

Once it's set, If I'm not rebuilding the toolset, I'd guess I go
straight to steps 2.5, 2.6 in the quick-start guide?

Thank you again for your help!

Sincerely,

Matt

On Tue, Jun 29, 2021 at 3:45 PM Joel Sherrill  wrote:
>
> On Tue, Jun 29, 2021 at 8:07 AM Matthew Joyce  wrote:
> >
> > Dear Mentors,
> >
> > I've implemented my new functions locally in Newlib, created basic
> > tests in RTEMS, now I want to add the patches to the RSB to test them.
> >
> > I think I understand that once I submit these patches to newlib, they
> > should only include the added lines of source code...not any changes
> > generated through the build process.
>
> +1
>
> > However, when I make a patch to add to RSB and test, I need to include
> > everything, right? There are probably about 100 modified files from
> > the reconf / build. Should I:
> > 1) "git add --all" to add the whole load of new files and changes
> > 2) make the commit
> > 3) git format patch
>
> Yes -- the RSB patch must include the generated files. But this patch set
> and RSB modifications are only for your use. Before RTEMS.org RSB is
> updated, the patch must be in the upstream newlib and we will just bump
> the newlib hash. That's why I suggested just building newlib (j-newlib, make,
> make install, etc) locally without the RSB and testing that way.
>
> With that said, there are a couple of things to do here:
>
> + Do NOT put generated files in your main patch. Make them a separate
> patch in the set so they are easy to ignore.
>
> + Reverse the generated changes to anything that shouldn't change based
> on what you touched. These are just due to autoconf version difference. In 
> your
> case, I think this means you only need signal/Makefile.in. The rest are
> unneeded.
>
> + Only submit the patches with manual changes for review. Submit to devel@
> and when it passes review, it goes to newlib.
>
> When the work is merged into newlib, you can update the RSB newlib hash
> and submit your tests to RTEMS. You will have to track the status of
> outstanding work and continue on to the next thing while the review process
> moves along.
>
> FWIW Eshan ended up tracking patches for a few months after last year's
> GSoC ended before we cleared his queue up.
>
> --joel
>
> >
> > Just want to make sure I'm understanding this point...
> >
> > Thank you!
> >
> > Sincerely,
> >
> > Matt
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

GSOC: Adding all generated changes in patch to RSB?

[Matthew Joyce]

Dear Mentors,

I've implemented my new functions locally in Newlib, created basic
tests in RTEMS, now I want to add the patches to the RSB to test them.

I think I understand that once I submit these patches to newlib, they
should only include the added lines of source code...not any changes
generated through the build process.

However, when I make a patch to add to RSB and test, I need to include
everything, right? There are probably about 100 modified files from
the reconf / build. Should I:
1) "git add --all" to add the whole load of new files and changes
2) make the commit
3) git format patch

Just want to make sure I'm understanding this point...

Thank you!

Sincerely,

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

Re: GSoC POSIX Compliance: Can't Build RTEMS Tool Suite Anymore

[Matthew Joyce]

Thanks for your note, Sir! I'll never get that day back, but I'm glad to be
back on track now and have made
a bit of progress.

I made the change locally in libc/sys/signal.h to use the *__restrict. I
then configured and (successfully!)
built newlib for sparc-rtems6. I see the various build binaries in the
b-sparc-rtems6-newlib directory. I nm
them for the newly declared functions, for example: sparc-rtems6-nm
/libc.a | grep sig2str but
they don't show up at all. Would symbols show up in the binaries after
being declared (but not defined)?
Where do I go from here to ensure this prototype patch is good to go to
submit to Newlib?

Also, you wrote:
"...as long as you are working on patches to newlib, it is simpler and much
quicker to just build newlib
and install it over the RSB built version. You do not need to rebuild gcc,
binutils, or gdb."

Could you please elaborate on what you mean by "just build newlib and
install it over the RSB built version"?

Thank you very much for your time!

Sincerely,

Matt


On Jun 18, 2021, at 5:17 PM, Joel Sherrill  wrote:




On Fri, Jun 18, 2021 at 8:33 AM Matthew Joyce  wrote:

> Dear Mentors,
>
> I'm sorry to report that I've taken one step forward and three steps
> back. Since last night, I'm having trouble building the RTEMS tool
> suite at all. I keep getting the same error (attached).
>
> Steps I've taken to attempt to resolve:
> 1) Tried to check out previous commits and rebuild from there.
> 2) sudo yum update && upgrade
>

Did the native gcc or binutils update? The failure looks like an assembler
issue with gcc output but weird since it is a partial line error. Did you
run out of disk space?


> 3) Followed the quick-start guide from scratch (clone rsb and source
> into a new development directory, still fails in 2.4, Install the tool
> suite).
>
> How I got here: I applied my initial header patch to rsb using the
> blog guide and rebuilt the tool set. It built successfully, but then
> failed when I ran waf. (Compiler had issues with my use of the keyword
> "restrict".) I then created a new patch without "restrict", just to
> see if it would compile.


__restrict is what I hope you used and not just restrict. newlib uses
the __restrict macro it defines to ensure it only uses the restrict keyword
when it is supported by the language standard version being compiled with.


> I deleted the old patch from the
> tools/rtems-gcc-10-newlib-head.cfg and put the new one in.
>
> I'm guessing that was not correct based on my experience of the last 15
> hours!
>

You have to eventually deal with the RSB but as long as you are working
on patches to newlib, it is simpler and much quicker to just build newlib
and install it over the RSB built version. You do not need to rebuild gcc,
binutils, or gdb.

With the locally updated newlib, make changes to your local RTEMS
to add methods and/or tests.

When the newlib side is ready, submit the patch for review. When that
is merged, the newlib version in the RSB will need to be bumped.
After the newlib RSB hash is bumped, then things are in place to submit
your RTEMS modifications.

Streamlining the build/test cycle like this may save an hour an iteration.

You usually can't submit a newlib change and a corresponding RTEMS
change in parallel anyway. They have to be sequenced because of the
dependency.


>
> I'm really looking forward to your feedback and advice when you can.
> Thank you again!
>
> Sincerely,
>
> Matt
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] libc: Added sig2str/str2sig prototypes

[Matthew Joyce]

Hi Eshan,

Thanks very much for this...It's really helpful!

Question on workflow:
So for this example, I just apply the patch to RSB. Do I understand correctly
that we need to rebuild the tool chain each and every time I make any
change? (Step 7 in
Vaibhav's Blog) This didn't compile, apparently because of the double
restricts. Do I need
to make a change, rebuild the tool chain (around 1.33 hours), and test
again? Hopefully
there are shortcuts around that!

Thanks again for your help.

Sincerely,

Matt

On Wed, Jun 16, 2021 at 10:40 PM Eshan Dhawan  wrote:
>
> Hi Matt,
> Since you are making changes only to a header file you don’t need to run 
> autoreconf.
> You can directly apply the patch to RSB and it should work
> You need to run autoreconf when u make changes in makefile
> That is when u add a .c file
>
> > On 17-Jun-2021, at 1:53 AM, Matt Joyce  wrote:
> >
> > ***As Requested: For Review Only. Does Not Compile***
> >
> > Added definition of SIG2STR_MAX and function prototypes for sig2str
> > and str2sig in sys/signal.h in order to improve POSIX compliance.
> > ---
> > newlib/libc/include/sys/signal.h | 12 
> > 1 file changed, 12 insertions(+)
> >
> > diff --git a/newlib/libc/include/sys/signal.h 
> > b/newlib/libc/include/sys/signal.h
> > index 45cc0366c..fd2b3c672 100644
> > --- a/newlib/libc/include/sys/signal.h
> > +++ b/newlib/libc/include/sys/signal.h
> > @@ -238,6 +238,18 @@ int sigqueue (pid_t, int, const union sigval);
> >
> > #endif /* __POSIX_VISIBLE >= 199309 */
> >
> > +#if __GNU_VISIBLE
> > +
> > +/* 202x_d2-POSIX-Issue-8, p. 327 adds SIG2STR_MAX, p. 332 adds sig2str()
> > +   and str2sig(). */
> > +
> > +#define SIG2STR_MAX 4294967295
> > +
> > +int sig2str(int, char *);
> > +int str2sig(const char *restrict, int *restrict);
> > +
> > +#endif /* __GNU_VISIBLE  */
> > +
> > #if defined(___AM29K__)
> > /* These all need to be defined for ANSI C, but I don't think they are
> >meaningful.  */
> > --
> > 2.31.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: GSOC POSIX Compliance: Stuck trying to build Newlib

[Matthew Joyce]

Ok, thanks!

I'm about to sign off for dinner,  but I'll send the patch (with
disclaimer) tonight.  So since the code fails to compile, I need to
start making some changes. Do I need to rebuild the rtems tool chain
each time? I'm averaging about 1.33 hours on that :-( . Is that where
some of the scripts you sent help out?

Sorry we didn't connect tonight, but please let me know if there's
another day this week you could chat!

Thanks so much for everybody's patience and support!

Sincerely,

Matt

On Wed, Jun 16, 2021 at 6:43 PM Joel Sherrill  wrote:
>
>
>
> On Wed, Jun 16, 2021 at 11:37 AM Matthew Joyce  wrote:
>>
>> I hate to ask, but where should the build binaries be if "make all"
>> was actually successful?
>
>
> For newlib, there should be various libc.a and libm.a files in the build 
> directory.
>
> Use find to locate them: find . -name libc.a
>
> And use "nm" to find out if the symbol is there.
>
> sparc-rtems6-nm .../libc.a
>
> You can save that output or pipe it to less.
>
> Note: paths need to be adjusted to the files.
>
> --joel
>>
>>
>> Thanks!
>>
>> Matt
>>
>> On Wed, Jun 16, 2021 at 6:16 PM Eshan Dhawan  wrote:
>> >
>> > Hi Matt,
>> > > On 16-Jun-2021, at 9:27 PM, Matthew Joyce  wrote:
>> > >
>> > > Hi Dr. Joel,
>> > >
>> > > I tried that in newlib/libc and there were at least no errors.
>> > > (Nothing leading me to believe it was successful either!)
>> > >
>> > > However I still got the same error when I sudo make install.
>> > > (sparc-rtems-ranlib: command not found) (among others!)
>> > >
>> > I make works then there is no need to run make install it just copies the 
>> > build binaries to the root folders.
>> >
>> > If make is build with the changes u made and the symbols that you added 
>> > appear in the binaries you generated.
>> > Then congratulations :)
>> > Now you just need to test those changes in the RSB to test they don’t 
>> > break anything in the RTEMS ecosystem.
>> > > Thanks again!
>> > >
>> > > Sincerely,
>> > >
>> > > Matt
>> > >
>> > >
>> > >
>> > >> On Wed, Jun 16, 2021 at 3:06 PM Joel Sherrill  wrote:
>> > >>
>> > >> Does adding --no-recursive and running it only from the directory you 
>> > >> touched a build system file in help?
>> > >>
>> > >> It is regenerating a lot you don't want to touch anyway.
>> > >>
>> > >> --joel
>> > >>
>> > >>> On Wed, Jun 16, 2021, 5:32 AM Matthew Joyce  
>> > >>> wrote:
>> > >>>
>> > >>> Hi Eshan,
>> > >>>
>> > >>> Thanks very much for your follow up! Ok, I see now that if I go into
>> > >>> development/newlib/newlib-cygwin/newlib and run autoreconf -fvi with
>> > >>> the v2.69 using the PATH that Dr. Joel just showed, it starts to run.
>> > >>> It always eventually exits with an error though. (please see attached
>> > >>> .txt). I hope you can read that...I used the command "script" to
>> > >>> output everything to a text file.
>> > >>>
>> > >>> Do you have any idea where I might be going wrong?
>> > >>>
>> > >>> Thank you!
>> > >>>
>> > >>> Sincerely,
>> > >>>
>> > >>> Matt
>> > >>>
>> > >>> On Tue, Jun 15, 2021 at 8:23 PM Eshan Dhawan  
>> > >>> wrote:
>> > >>>>
>> > >>>> Hi matt
>> > >>>> It would work if run inside newlib instead of newlib-cygwin
>> > >>>> run command inside of ../newlib-cygwin/newlib
>> > >>>> instead of ../newlib-cygwin
>> > >>>>
>> > >>>>
>> > >>>> On Tue, Jun 15, 2021 at 10:59 PM Matthew Joyce 
>> > >>>>  wrote:
>> > >>>>>
>> > >>>>> Ah, ok will do! Thank you for the tip.
>> > >>>>>
>> > >>>>> On Tue, Jun 15, 2021 at 7:17 PM Gedare Bloom  
>> > >>>>> wrote:
>> > >>>>>>
>> > >>>>>> Just a note, it's more efficient to capture your terminal dump into 
>> > >>>>

Re: GSOC POSIX Compliance: Stuck trying to build Newlib

[Matthew Joyce]

I hate to ask, but where should the build binaries be if "make all"
was actually successful?

Thanks!

Matt

On Wed, Jun 16, 2021 at 6:16 PM Eshan Dhawan  wrote:
>
> Hi Matt,
> > On 16-Jun-2021, at 9:27 PM, Matthew Joyce  wrote:
> >
> > Hi Dr. Joel,
> >
> > I tried that in newlib/libc and there were at least no errors.
> > (Nothing leading me to believe it was successful either!)
> >
> > However I still got the same error when I sudo make install.
> > (sparc-rtems-ranlib: command not found) (among others!)
> >
> I make works then there is no need to run make install it just copies the 
> build binaries to the root folders.
>
> If make is build with the changes u made and the symbols that you added 
> appear in the binaries you generated.
> Then congratulations :)
> Now you just need to test those changes in the RSB to test they don’t break 
> anything in the RTEMS ecosystem.
> > Thanks again!
> >
> > Sincerely,
> >
> > Matt
> >
> >
> >
> >> On Wed, Jun 16, 2021 at 3:06 PM Joel Sherrill  wrote:
> >>
> >> Does adding --no-recursive and running it only from the directory you 
> >> touched a build system file in help?
> >>
> >> It is regenerating a lot you don't want to touch anyway.
> >>
> >> --joel
> >>
> >>> On Wed, Jun 16, 2021, 5:32 AM Matthew Joyce  wrote:
> >>>
> >>> Hi Eshan,
> >>>
> >>> Thanks very much for your follow up! Ok, I see now that if I go into
> >>> development/newlib/newlib-cygwin/newlib and run autoreconf -fvi with
> >>> the v2.69 using the PATH that Dr. Joel just showed, it starts to run.
> >>> It always eventually exits with an error though. (please see attached
> >>> .txt). I hope you can read that...I used the command "script" to
> >>> output everything to a text file.
> >>>
> >>> Do you have any idea where I might be going wrong?
> >>>
> >>> Thank you!
> >>>
> >>> Sincerely,
> >>>
> >>> Matt
> >>>
> >>> On Tue, Jun 15, 2021 at 8:23 PM Eshan Dhawan  
> >>> wrote:
> >>>>
> >>>> Hi matt
> >>>> It would work if run inside newlib instead of newlib-cygwin
> >>>> run command inside of ../newlib-cygwin/newlib
> >>>> instead of ../newlib-cygwin
> >>>>
> >>>>
> >>>> On Tue, Jun 15, 2021 at 10:59 PM Matthew Joyce  
> >>>> wrote:
> >>>>>
> >>>>> Ah, ok will do! Thank you for the tip.
> >>>>>
> >>>>> On Tue, Jun 15, 2021 at 7:17 PM Gedare Bloom  wrote:
> >>>>>>
> >>>>>> Just a note, it's more efficient to capture your terminal dump into a
> >>>>>> text file and attach that, rather than put a screenshot up.
> >>>>>>
> >>>>>> On Tue, Jun 15, 2021 at 11:14 AM Matthew Joyce  
> >>>>>> wrote:
> >>>>>>>
> >>>>>>> Hi Gentlemen,
> >>>>>>>
> >>>>>>> Thanks very much for your quick replies!
> >>>>>>>
> >>>>>>> I just tried both, but perhaps I'm misinterpreting your suggestions.
> >>>>>>> (Could you please see the attached commands / errors!)
> >>>>>>>
> >>>>>>> Eshan,
> >>>>>>>
> >>>>>>> I did see that link, but it wasn't clear to me what the solution 
> >>>>>>> was...Sorry!
> >>>>>>>
> >>>>>>> Sincerely,
> >>>>>>>
> >>>>>>> Matt
> >>>>>>>
> >>>>>>> On Tue, Jun 15, 2021 at 6:52 PM Eshan Dhawan 
> >>>>>>>  wrote:
> >>>>>>>>
> >>>>>>>> Hi Matt,
> >>>>>>>> Try running the command with autoconf version 2.69 that's shipped 
> >>>>>>>> with RTEMS in the rtems bin
> >>>>>>>> That works as well.
> >>>>>>>>
> >>>>>>>> Also From a quick google search this is what I found : 
> >>>>>>>> https://superuser.com/questions/617872/cant-locate-autom4te-channeldefs-pm-in-inc-when-it-definitely-is-there
> >>>>>>>>
> >>

Re: GSOC POSIX Compliance: Stuck trying to build Newlib

[Matthew Joyce]

Hi Dr. Joel,

I used the following, based on Vaibhav's blog:

$ export PATH=$HOME/development/rtems/6/bin:$PATH

$ ../newlib-cygwin/configure --target=sparc-rtems6 --disable-shared
--disable-nls --enable-werror --enable-newlib-supplied-syscalls
--enable-interwork --enable-multilib --with-gnu-as --with-gnu-ld

When I enter "type sparc-rtems6-gcc" (I hope I'm understanding that
correctly!), I get sparc-rtems6-gcc is hashed...and then my PATH.

Thanks again!

V/r,

Matt

On Wed, Jun 16, 2021 at 6:06 PM Joel Sherrill  wrote:
>
>
>
> On Wed, Jun 16, 2021 at 10:57 AM Matthew Joyce  wrote:
>>
>> Hi Dr. Joel,
>>
>> I tried that in newlib/libc and there were at least no errors.
>> (Nothing leading me to believe it was successful either!)
>>
>> However I still got the same error when I sudo make install.
>> (sparc-rtems-ranlib: command not found) (among others!)
>
>
> The target should be sparc-rtems6 when you configure newlib.
> This should mean invoking the script like "./j-newlib sparc-rtems6"
>
>
> And the RTEMS tools should be in your PATH.
>
> type sparc-rtems6-gcc
>
> To be sure.
>
> --joel
>>
>>
>> Thanks again!
>>
>> Sincerely,
>>
>> Matt
>>
>>
>>
>> On Wed, Jun 16, 2021 at 3:06 PM Joel Sherrill  wrote:
>> >
>> > Does adding --no-recursive and running it only from the directory you 
>> > touched a build system file in help?
>> >
>> > It is regenerating a lot you don't want to touch anyway.
>> >
>> > --joel
>> >
>> > On Wed, Jun 16, 2021, 5:32 AM Matthew Joyce  wrote:
>> >>
>> >> Hi Eshan,
>> >>
>> >> Thanks very much for your follow up! Ok, I see now that if I go into
>> >> development/newlib/newlib-cygwin/newlib and run autoreconf -fvi with
>> >> the v2.69 using the PATH that Dr. Joel just showed, it starts to run.
>> >> It always eventually exits with an error though. (please see attached
>> >> .txt). I hope you can read that...I used the command "script" to
>> >> output everything to a text file.
>> >>
>> >> Do you have any idea where I might be going wrong?
>> >>
>> >> Thank you!
>> >>
>> >> Sincerely,
>> >>
>> >> Matt
>> >>
>> >> On Tue, Jun 15, 2021 at 8:23 PM Eshan Dhawan  
>> >> wrote:
>> >> >
>> >> > Hi matt
>> >> > It would work if run inside newlib instead of newlib-cygwin
>> >> > run command inside of ../newlib-cygwin/newlib
>> >> > instead of ../newlib-cygwin
>> >> >
>> >> >
>> >> > On Tue, Jun 15, 2021 at 10:59 PM Matthew Joyce  
>> >> > wrote:
>> >> >>
>> >> >> Ah, ok will do! Thank you for the tip.
>> >> >>
>> >> >> On Tue, Jun 15, 2021 at 7:17 PM Gedare Bloom  wrote:
>> >> >> >
>> >> >> > Just a note, it's more efficient to capture your terminal dump into a
>> >> >> > text file and attach that, rather than put a screenshot up.
>> >> >> >
>> >> >> > On Tue, Jun 15, 2021 at 11:14 AM Matthew Joyce 
>> >> >> >  wrote:
>> >> >> > >
>> >> >> > > Hi Gentlemen,
>> >> >> > >
>> >> >> > > Thanks very much for your quick replies!
>> >> >> > >
>> >> >> > > I just tried both, but perhaps I'm misinterpreting your 
>> >> >> > > suggestions.
>> >> >> > > (Could you please see the attached commands / errors!)
>> >> >> > >
>> >> >> > > Eshan,
>> >> >> > >
>> >> >> > > I did see that link, but it wasn't clear to me what the solution 
>> >> >> > > was...Sorry!
>> >> >> > >
>> >> >> > > Sincerely,
>> >> >> > >
>> >> >> > > Matt
>> >> >> > >
>> >> >> > > On Tue, Jun 15, 2021 at 6:52 PM Eshan Dhawan 
>> >> >> > >  wrote:
>> >> >> > > >
>> >> >> > > > Hi Matt,
>> >> >> > > > Try running the command with autoconf version 2.69 that's 
>> >> >> > > > shipped with RTEMS in the rtems bin
>

Re: GSOC POSIX Compliance: Stuck trying to build Newlib

[Matthew Joyce]

Hi Dr. Joel,

I tried that in newlib/libc and there were at least no errors.
(Nothing leading me to believe it was successful either!)

However I still got the same error when I sudo make install.
(sparc-rtems-ranlib: command not found) (among others!)

Thanks again!

Sincerely,

Matt



On Wed, Jun 16, 2021 at 3:06 PM Joel Sherrill  wrote:
>
> Does adding --no-recursive and running it only from the directory you touched 
> a build system file in help?
>
> It is regenerating a lot you don't want to touch anyway.
>
> --joel
>
> On Wed, Jun 16, 2021, 5:32 AM Matthew Joyce  wrote:
>>
>> Hi Eshan,
>>
>> Thanks very much for your follow up! Ok, I see now that if I go into
>> development/newlib/newlib-cygwin/newlib and run autoreconf -fvi with
>> the v2.69 using the PATH that Dr. Joel just showed, it starts to run.
>> It always eventually exits with an error though. (please see attached
>> .txt). I hope you can read that...I used the command "script" to
>> output everything to a text file.
>>
>> Do you have any idea where I might be going wrong?
>>
>> Thank you!
>>
>> Sincerely,
>>
>> Matt
>>
>> On Tue, Jun 15, 2021 at 8:23 PM Eshan Dhawan  wrote:
>> >
>> > Hi matt
>> > It would work if run inside newlib instead of newlib-cygwin
>> > run command inside of ../newlib-cygwin/newlib
>> > instead of ../newlib-cygwin
>> >
>> >
>> > On Tue, Jun 15, 2021 at 10:59 PM Matthew Joyce  
>> > wrote:
>> >>
>> >> Ah, ok will do! Thank you for the tip.
>> >>
>> >> On Tue, Jun 15, 2021 at 7:17 PM Gedare Bloom  wrote:
>> >> >
>> >> > Just a note, it's more efficient to capture your terminal dump into a
>> >> > text file and attach that, rather than put a screenshot up.
>> >> >
>> >> > On Tue, Jun 15, 2021 at 11:14 AM Matthew Joyce  
>> >> > wrote:
>> >> > >
>> >> > > Hi Gentlemen,
>> >> > >
>> >> > > Thanks very much for your quick replies!
>> >> > >
>> >> > > I just tried both, but perhaps I'm misinterpreting your suggestions.
>> >> > > (Could you please see the attached commands / errors!)
>> >> > >
>> >> > > Eshan,
>> >> > >
>> >> > > I did see that link, but it wasn't clear to me what the solution 
>> >> > > was...Sorry!
>> >> > >
>> >> > > Sincerely,
>> >> > >
>> >> > > Matt
>> >> > >
>> >> > > On Tue, Jun 15, 2021 at 6:52 PM Eshan Dhawan 
>> >> > >  wrote:
>> >> > > >
>> >> > > > Hi Matt,
>> >> > > > Try running the command with autoconf version 2.69 that's shipped 
>> >> > > > with RTEMS in the rtems bin
>> >> > > > That works as well.
>> >> > > >
>> >> > > > Also From a quick google search this is what I found : 
>> >> > > > https://superuser.com/questions/617872/cant-locate-autom4te-channeldefs-pm-in-inc-when-it-definitely-is-there
>> >> > > >
>> >> > > > On Tue, Jun 15, 2021 at 9:12 PM Matthew Joyce 
>> >> > > >  wrote:
>> >> > > >>
>> >> > > >> Hello Dr. Joel and Eshan,
>> >> > > >>
>> >> > > >> I have a patch ready to send to Newlib for the sig function 
>> >> > > >> prototypes
>> >> > > >> and STR2SIG_MAX.
>> >> > > >>
>> >> > > >> But to do that, I think I need to have Newlib built, which I must
>> >> > > >> still be doing wrong. The error that I am getting is attached 
>> >> > > >> below.
>> >> > > >>
>> >> > > >> I’ve been trying to follow the steps here:
>> >> > > >> https://medium.com/my-gsoc-2019-journey/apply-newlib-patch-to-rtems-source-builder-6873b0fb31b8
>> >> > > >> and 
>> >> > > >> https://medium.com/my-gsoc-2019-journey/build-newlib-for-sparc-and-arm-architecture-6b3287d4c6f2
>> >> > > >>
>> >> > > >> I even had rebuilt everything from scratch to see if that would 
>> >> > > >> help,
>> >> > > >> but I still get the same error. Maybe I cloned the newlib source 
>> >> > > >> into
>> >> > > >> the wrong directory?
>> >> > > >>
>> >> > > >> I was hoping to get the patch off to Newlib for review as a first 
>> >> > > >> step
>> >> > > >> while I work on writing the actual methods. When you get a moment,
>> >> > > >> could you please advise? Thank you very much!
>> >> > > >>
>> >> > > >> Sincerely,
>> >> > > >>
>> >> > > >> Matt
>> >> > > ___
>> >> > > 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: GSOC POSIX Compliance: Stuck trying to build Newlib

[Matthew Joyce]

Hi Eshan,

Thanks very much for your follow up! Ok, I see now that if I go into
development/newlib/newlib-cygwin/newlib and run autoreconf -fvi with
the v2.69 using the PATH that Dr. Joel just showed, it starts to run.
It always eventually exits with an error though. (please see attached
.txt). I hope you can read that...I used the command "script" to
output everything to a text file.

Do you have any idea where I might be going wrong?

Thank you!

Sincerely,

Matt

On Tue, Jun 15, 2021 at 8:23 PM Eshan Dhawan  wrote:
>
> Hi matt
> It would work if run inside newlib instead of newlib-cygwin
> run command inside of ../newlib-cygwin/newlib
> instead of ../newlib-cygwin
>
>
> On Tue, Jun 15, 2021 at 10:59 PM Matthew Joyce  wrote:
>>
>> Ah, ok will do! Thank you for the tip.
>>
>> On Tue, Jun 15, 2021 at 7:17 PM Gedare Bloom  wrote:
>> >
>> > Just a note, it's more efficient to capture your terminal dump into a
>> > text file and attach that, rather than put a screenshot up.
>> >
>> > On Tue, Jun 15, 2021 at 11:14 AM Matthew Joyce  
>> > wrote:
>> > >
>> > > Hi Gentlemen,
>> > >
>> > > Thanks very much for your quick replies!
>> > >
>> > > I just tried both, but perhaps I'm misinterpreting your suggestions.
>> > > (Could you please see the attached commands / errors!)
>> > >
>> > > Eshan,
>> > >
>> > > I did see that link, but it wasn't clear to me what the solution 
>> > > was...Sorry!
>> > >
>> > > Sincerely,
>> > >
>> > > Matt
>> > >
>> > > On Tue, Jun 15, 2021 at 6:52 PM Eshan Dhawan  
>> > > wrote:
>> > > >
>> > > > Hi Matt,
>> > > > Try running the command with autoconf version 2.69 that's shipped with 
>> > > > RTEMS in the rtems bin
>> > > > That works as well.
>> > > >
>> > > > Also From a quick google search this is what I found : 
>> > > > https://superuser.com/questions/617872/cant-locate-autom4te-channeldefs-pm-in-inc-when-it-definitely-is-there
>> > > >
>> > > > On Tue, Jun 15, 2021 at 9:12 PM Matthew Joyce  
>> > > > wrote:
>> > > >>
>> > > >> Hello Dr. Joel and Eshan,
>> > > >>
>> > > >> I have a patch ready to send to Newlib for the sig function prototypes
>> > > >> and STR2SIG_MAX.
>> > > >>
>> > > >> But to do that, I think I need to have Newlib built, which I must
>> > > >> still be doing wrong. The error that I am getting is attached below.
>> > > >>
>> > > >> I’ve been trying to follow the steps here:
>> > > >> https://medium.com/my-gsoc-2019-journey/apply-newlib-patch-to-rtems-source-builder-6873b0fb31b8
>> > > >> and 
>> > > >> https://medium.com/my-gsoc-2019-journey/build-newlib-for-sparc-and-arm-architecture-6b3287d4c6f2
>> > > >>
>> > > >> I even had rebuilt everything from scratch to see if that would help,
>> > > >> but I still get the same error. Maybe I cloned the newlib source into
>> > > >> the wrong directory?
>> > > >>
>> > > >> I was hoping to get the patch off to Newlib for review as a first step
>> > > >> while I work on writing the actual methods. When you get a moment,
>> > > >> could you please advise? Thank you very much!
>> > > >>
>> > > >> Sincerely,
>> > > >>
>> > > >> Matt
>> > > ___
>> > > devel mailing list
>> > > devel@rtems.org
>> > > http://lists.rtems.org/mailman/listinfo/devel
Script started on 2021-06-16 11:49:24+02:00 [TERM="xterm-256color" 
TTY="/dev/pts/0" COLUMNS="129" LINES="33"]
]777;notify;Command 
completed;exit\]777;precmd\]0;mj@fedora:~/development/newlib/newlib-cygwin/newlib\]7;file://fedora/home/mj/development/newlib/newlib-cygwin/newlib\[mj@localhost
 newlib]$ cd ~/development/newlib/newlib-cygwin/newlib/
]777;preexec\]777;notify;Command completed;cd 
~/development/newlib/newlib-cygwin/newlib/\]777;precmd\]0;mj@fedora:~/development/newlib/newlib-cygwin/newlib\]7;file://fedora/home/mj/development/newlib/newlib-cygwin/newlib\[mj@localhost
 newlib]$ autoconf -V
]777;preexec\autoconf (GNU Autoconf) 2.64
Copyright (C) 2009 Free Software Foundation, Inc.
License 

Re: GSOC POSIX Compliance: Stuck trying to build Newlib

[Matthew Joyce]

Hi Vaibhav,

Thanks very much for your note!  Fantastic job on your blogs. I read
the entry on managing the two versions of autoconf and have been
trying to follow it carefully. Could you please see the attached txt
file?

I'm in development/newlib/newlib-cygwin. I get the error where it
tells me to use exactly autoconf 2.64 and not 2.69. I change the $PATH
to make sure it is checking the opt/autoconf-2.64/bin first.

I check the autoconf version and confirm that it is now using 2.64.
But then when I try to run autoreconf -fvi, I get the same error as I
had yesterday.

Do you have any ideas as to what I'm doing wrong?

Thanks again!

Sincerely,

Matt

On Wed, Jun 16, 2021 at 4:36 AM Vaibhav Gupta  wrote:
>
> Hello Matthew,
>
> On Wed, Jun 16, 2021 at 12:58 AM Joel Sherrill  wrote:
> >
> > @RTEMS_TOOLS_BIN@ should have been replaced with the real directory where 
> > your RTEMS tools are located. Something like this:
>
> Exactly. I was wondering the same when I saw his output of 'echo $PATH'.
> Matthew, the newlib and autoconf relationship is a bit messy. But you
> can simplify it if you use $PATH carefully.
> Have a look at this
> https://medium.com/my-gsoc-2019-journey/how-to-handle-two-versions-of-autoconf-b1e28de8617b,
> the path should expand and should point to the correct binaries.
>
> The blog should give you an idea of how the $PATH works and how it
> should be modified.
>
>
> -- Vaibhav Gupta
> >
> > $ export PATH=${HOME}/rtems-work/tools/6/bin:$PATH
> >
> > And to check you have the PATH right, do something like this:
> >
> > $ type sparc-rtems6-gcc
> > sparc-rtems6-gcc is /home/joel/rtems-work/tools/6/bin/sparc-rtems6-gcc
> >
> > On Tue, Jun 15, 2021 at 1:23 PM Eshan Dhawan  
> > wrote:
> >>
> >> Hi matt
> >> It would work if run inside newlib instead of newlib-cygwin
> >> run command inside of ../newlib-cygwin/newlib
> >> instead of ../newlib-cygwin
> >>
> >>
> >> On Tue, Jun 15, 2021 at 10:59 PM Matthew Joyce  
> >> wrote:
> >>>
> >>> Ah, ok will do! Thank you for the tip.
> >>>
> >>> On Tue, Jun 15, 2021 at 7:17 PM Gedare Bloom  wrote:
> >>> >
> >>> > Just a note, it's more efficient to capture your terminal dump into a
> >>> > text file and attach that, rather than put a screenshot up.
> >>> >
> >>> > On Tue, Jun 15, 2021 at 11:14 AM Matthew Joyce  
> >>> > wrote:
> >>> > >
> >>> > > Hi Gentlemen,
> >>> > >
> >>> > > Thanks very much for your quick replies!
> >>> > >
> >>> > > I just tried both, but perhaps I'm misinterpreting your suggestions.
> >>> > > (Could you please see the attached commands / errors!)
> >>> > >
> >>> > > Eshan,
> >>> > >
> >>> > > I did see that link, but it wasn't clear to me what the solution 
> >>> > > was...Sorry!
> >>> > >
> >>> > > Sincerely,
> >>> > >
> >>> > > Matt
> >>> > >
> >>> > > On Tue, Jun 15, 2021 at 6:52 PM Eshan Dhawan 
> >>> > >  wrote:
> >>> > > >
> >>> > > > Hi Matt,
> >>> > > > Try running the command with autoconf version 2.69 that's shipped 
> >>> > > > with RTEMS in the rtems bin
> >>> > > > That works as well.
> >>> > > >
> >>> > > > Also From a quick google search this is what I found : 
> >>> > > > https://superuser.com/questions/617872/cant-locate-autom4te-channeldefs-pm-in-inc-when-it-definitely-is-there
> >>> > > >
> >>> > > > On Tue, Jun 15, 2021 at 9:12 PM Matthew Joyce 
> >>> > > >  wrote:
> >>> > > >>
> >>> > > >> Hello Dr. Joel and Eshan,
> >>> > > >>
> >>> > > >> I have a patch ready to send to Newlib for the sig function 
> >>> > > >> prototypes
> >>> > > >> and STR2SIG_MAX.
> >>> > > >>
> >>> > > >> But to do that, I think I need to have Newlib built, which I must
> >>> > > >> still be doing wrong. The error that I am getting is attached 
> >>> > > >> below.
> >>> > > >>
> >>> > > >> I’ve been trying to follow the steps here:
> >>>

Re: GSOC POSIX Compliance: Stuck trying to build Newlib

[Matthew Joyce]

Ah, ok will do! Thank you for the tip.

On Tue, Jun 15, 2021 at 7:17 PM Gedare Bloom  wrote:
>
> Just a note, it's more efficient to capture your terminal dump into a
> text file and attach that, rather than put a screenshot up.
>
> On Tue, Jun 15, 2021 at 11:14 AM Matthew Joyce  wrote:
> >
> > Hi Gentlemen,
> >
> > Thanks very much for your quick replies!
> >
> > I just tried both, but perhaps I'm misinterpreting your suggestions.
> > (Could you please see the attached commands / errors!)
> >
> > Eshan,
> >
> > I did see that link, but it wasn't clear to me what the solution 
> > was...Sorry!
> >
> > Sincerely,
> >
> > Matt
> >
> > On Tue, Jun 15, 2021 at 6:52 PM Eshan Dhawan  
> > wrote:
> > >
> > > Hi Matt,
> > > Try running the command with autoconf version 2.69 that's shipped with 
> > > RTEMS in the rtems bin
> > > That works as well.
> > >
> > > Also From a quick google search this is what I found : 
> > > https://superuser.com/questions/617872/cant-locate-autom4te-channeldefs-pm-in-inc-when-it-definitely-is-there
> > >
> > > On Tue, Jun 15, 2021 at 9:12 PM Matthew Joyce  
> > > wrote:
> > >>
> > >> Hello Dr. Joel and Eshan,
> > >>
> > >> I have a patch ready to send to Newlib for the sig function prototypes
> > >> and STR2SIG_MAX.
> > >>
> > >> But to do that, I think I need to have Newlib built, which I must
> > >> still be doing wrong. The error that I am getting is attached below.
> > >>
> > >> I’ve been trying to follow the steps here:
> > >> https://medium.com/my-gsoc-2019-journey/apply-newlib-patch-to-rtems-source-builder-6873b0fb31b8
> > >> and 
> > >> https://medium.com/my-gsoc-2019-journey/build-newlib-for-sparc-and-arm-architecture-6b3287d4c6f2
> > >>
> > >> I even had rebuilt everything from scratch to see if that would help,
> > >> but I still get the same error. Maybe I cloned the newlib source into
> > >> the wrong directory?
> > >>
> > >> I was hoping to get the patch off to Newlib for review as a first step
> > >> while I work on writing the actual methods. When you get a moment,
> > >> could you please advise? Thank you very much!
> > >>
> > >> Sincerely,
> > >>
> > >> Matt
> > ___
> > 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: GSOC POSIX Compliance: Stuck trying to build Newlib

[Matthew Joyce]

Hi Gentlemen,

Thanks very much for your quick replies!

I just tried both, but perhaps I'm misinterpreting your suggestions.
(Could you please see the attached commands / errors!)

Eshan,

I did see that link, but it wasn't clear to me what the solution was...Sorry!

Sincerely,

Matt

On Tue, Jun 15, 2021 at 6:52 PM Eshan Dhawan  wrote:
>
> Hi Matt,
> Try running the command with autoconf version 2.69 that's shipped with RTEMS 
> in the rtems bin
> That works as well.
>
> Also From a quick google search this is what I found : 
> https://superuser.com/questions/617872/cant-locate-autom4te-channeldefs-pm-in-inc-when-it-definitely-is-there
>
> On Tue, Jun 15, 2021 at 9:12 PM Matthew Joyce  wrote:
>>
>> Hello Dr. Joel and Eshan,
>>
>> I have a patch ready to send to Newlib for the sig function prototypes
>> and STR2SIG_MAX.
>>
>> But to do that, I think I need to have Newlib built, which I must
>> still be doing wrong. The error that I am getting is attached below.
>>
>> I’ve been trying to follow the steps here:
>> https://medium.com/my-gsoc-2019-journey/apply-newlib-patch-to-rtems-source-builder-6873b0fb31b8
>> and 
>> https://medium.com/my-gsoc-2019-journey/build-newlib-for-sparc-and-arm-architecture-6b3287d4c6f2
>>
>> I even had rebuilt everything from scratch to see if that would help,
>> but I still get the same error. Maybe I cloned the newlib source into
>> the wrong directory?
>>
>> I was hoping to get the patch off to Newlib for review as a first step
>> while I work on writing the actual methods. When you get a moment,
>> could you please advise? Thank you very much!
>>
>> Sincerely,
>>
>> Matt
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

GSOC POSIX Compliance: Stuck trying to build Newlib

[Matthew Joyce]

Hello Dr. Joel and Eshan,

I have a patch ready to send to Newlib for the sig function prototypes
and STR2SIG_MAX.

But to do that, I think I need to have Newlib built, which I must
still be doing wrong. The error that I am getting is attached below.

I’ve been trying to follow the steps here:
https://medium.com/my-gsoc-2019-journey/apply-newlib-patch-to-rtems-source-builder-6873b0fb31b8
and 
https://medium.com/my-gsoc-2019-journey/build-newlib-for-sparc-and-arm-architecture-6b3287d4c6f2

I even had rebuilt everything from scratch to see if that would help,
but I still get the same error. Maybe I cloned the newlib source into
the wrong directory?

I was hoping to get the patch off to Newlib for review as a first step
while I work on writing the actual methods. When you get a moment,
could you please advise? Thank you very much!

Sincerely,

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

Re: #4328: New APIs added to POSIX Standard (2021)

[Matthew Joyce]

Hi Dr. Joel,

Could you please point me to where I can find the API tracking CSV
file?  Thank you!

Sincerely,

Matt

On Tue, Apr 6, 2021 at 8:29 PM Joel Sherrill  wrote:
>
>
>
> On Thu, Apr 1, 2021 at 8:06 AM Gedare Bloom  wrote:
>>
>> On Thu, Apr 1, 2021 at 6:21 AM Matthew Joyce  wrote:
>> >
>> > Hi Dr. Joel and Dr. Gedare,
>> >
>> > I posted my draft proposal on the GSOC 2021 page
>> > (https://devel.rtems.org/wiki/GSoC/2021). At your convenience, I would
>> > be very grateful for any comments or additional guidance you might
>> > have.  Please note, I found implementations of some of the "clock"
>> > methods on glibc...does the GNU "Lesser General Public License" meet
>> > the intent for what RTEMS can use?
>> >
>> No. LGPL has a 'relinking' requirement that is not compatible.
>
>
> Also if I am right, the new "clock" methods should be straightforward to
> implement on RTEMS. Internally, there are "watchdog sets" which are
> based on different clock sources. I think now it is implicitly using one
> when it should allow the user to specify which "watchdog set" is used.
>
> And then.. tests.
>
> It was lost somewhere from an earlier message but the column
> "RTEMS w/ Networking" is intended to reflect adding rtems-libbsd.
>
> I also have a v10 of the spreadsheet in the queue which adds
> columns for FACE Technical Standard, Edition 3.1.
>
> If you spot methods that need adding, please post small patches
> so we can update rtems-docs and I can pick it up in v10.
>
>>
>>
>> > Also, regarding the spawn.h group of methods, do I understand
>> > correctly that they've been deliberately left out?  If so, I'm curious
>> > if there is anything that would still need to be done there. I noticed
>> > in the docs that some methods relating to new processes are supported
>> > in an adapted fashion (such as getpid()). Just wondering if there has
>> > been discussion on this for spawn so I can cover the bases.
>> >
>> RTEMS provides conceptually a single-process, multi-threaded, single
>> address space. So, any POSIX APIs that relate to multiple process
>> management tend to be unsupportable or meaningless. Spawn falls in the
>> same category as fork, it doesn't make sense to create a child process
>> in a single-process environment.
>
>
> This from the POSIX Compliance Guide may help:
>
> https://docs.rtems.org/branches/master/posix-compliance/preface.html
>
> If it isn't clear after that, then we need to update that section. :)
>
> Don't forget to get your proposal in.
>
> --joel
>>
>>
>> > Thank you very much for your time!
>> >
>> > Sincerely,
>> >
>> > Matt
>> >
>> > On Thu, Mar 25, 2021 at 2:18 PM Joel Sherrill  wrote:
>> > >
>> > >
>> > >
>> > > On Thu, Mar 25, 2021 at 7:14 AM Matthew Joyce  
>> > > wrote:
>> > >>
>> > >> Hi Dr. Joel,
>> > >>
>> > >> Thanks very much, that's a big help!  Correct, I've been updating the
>> > >> spreadsheet as I go along. Ok, now I see that strlcat/strlcpy are used
>> > >> in rtems/cpukit and implemented in Newlib.
>> > >>
>> > >> One additional question, please: I haven't yet looked into the source
>> > >> of NetBSD or FreeBSD, but I do see that Newlib already implements
>> > >> ppoll (poll.cc), dladdr (dlfcn.cc), pselect (select.cc), and
>> > >> sockatmark (net.cc). None of them are defined in the rtems environment
>> > >> yet. Is there any reason why the NetBSD/FreeBSD version would be
>> > >> preferable to Newlib for these? Or is it just a matter of testing
>> > >> what's out there to find what works well in the rtems environment?
>> > >
>> > >
>> > > Without looking at the newlib git repo, I can tell you that the files
>> > > you cite are the implementation of those methods for Cygwin. Just
>> > > because they are in C++. :)
>> > >
>> > > The parts of the newlib repo RTEMS uses are under the newlib/
>> > > subdirectory not the cygwin one. Within that, there is a libc/sys and
>> > > only libc/sys/rtems is used for RTEMS. The others are for different
>> > > operating systems. There are a few places with "machine" directory
>> > > structures. Only the ones for the architecture you are building for
>> > > is used.
>&g

Re: #4328: New APIs added to POSIX Standard (2021)

[Matthew Joyce]

Hi Eshan,

That would be awesome, thanks very much!

Matt

On Thu, Apr 1, 2021 at 5:02 PM Eshan Dhawan  wrote:
>
> Hi Matt,
> Glibc can’t be used due to license compatibility issues although you can see 
> there code for examples
> I have a list of all the sources that you can use
> The sources Joel gave handed me
> Where you can find potential candidates for porting methods
> (I will send the list when I reach home around midnight IST )
> In those you can look for methods by greping :)
> Thank
> - Eshan
> > On 01-Apr-2021, at 7:38 PM, Matthew Joyce  wrote:
> >
> > Dr. Gedare,
> >
> > Thanks for the info! Ok, I'll make sure to take out the glibc material.
> >
> > Sincerely,
> >
> > Matt
> >
> >> On Thu, Apr 1, 2021 at 3:06 PM Gedare Bloom  wrote:
> >>
> >>> On Thu, Apr 1, 2021 at 6:21 AM Matthew Joyce  
> >>> wrote:
> >>>
> >>> Hi Dr. Joel and Dr. Gedare,
> >>>
> >>> I posted my draft proposal on the GSOC 2021 page
> >>> (https://devel.rtems.org/wiki/GSoC/2021). At your convenience, I would
> >>> be very grateful for any comments or additional guidance you might
> >>> have.  Please note, I found implementations of some of the "clock"
> >>> methods on glibc...does the GNU "Lesser General Public License" meet
> >>> the intent for what RTEMS can use?
> >>>
> >> No. LGPL has a 'relinking' requirement that is not compatible.
> >>
> >>> Also, regarding the spawn.h group of methods, do I understand
> >>> correctly that they've been deliberately left out?  If so, I'm curious
> >>> if there is anything that would still need to be done there. I noticed
> >>> in the docs that some methods relating to new processes are supported
> >>> in an adapted fashion (such as getpid()). Just wondering if there has
> >>> been discussion on this for spawn so I can cover the bases.
> >>>
> >> RTEMS provides conceptually a single-process, multi-threaded, single
> >> address space. So, any POSIX APIs that relate to multiple process
> >> management tend to be unsupportable or meaningless. Spawn falls in the
> >> same category as fork, it doesn't make sense to create a child process
> >> in a single-process environment.
> >>
> >>> Thank you very much for your time!
> >>>
> >>> Sincerely,
> >>>
> >>> Matt
> >>>
> >>> On Thu, Mar 25, 2021 at 2:18 PM Joel Sherrill  wrote:
> >>>>
> >>>>
> >>>>
> >>>> On Thu, Mar 25, 2021 at 7:14 AM Matthew Joyce  
> >>>> wrote:
> >>>>>
> >>>>> Hi Dr. Joel,
> >>>>>
> >>>>> Thanks very much, that's a big help!  Correct, I've been updating the
> >>>>> spreadsheet as I go along. Ok, now I see that strlcat/strlcpy are used
> >>>>> in rtems/cpukit and implemented in Newlib.
> >>>>>
> >>>>> One additional question, please: I haven't yet looked into the source
> >>>>> of NetBSD or FreeBSD, but I do see that Newlib already implements
> >>>>> ppoll (poll.cc), dladdr (dlfcn.cc), pselect (select.cc), and
> >>>>> sockatmark (net.cc). None of them are defined in the rtems environment
> >>>>> yet. Is there any reason why the NetBSD/FreeBSD version would be
> >>>>> preferable to Newlib for these? Or is it just a matter of testing
> >>>>> what's out there to find what works well in the rtems environment?
> >>>>
> >>>>
> >>>> Without looking at the newlib git repo, I can tell you that the files
> >>>> you cite are the implementation of those methods for Cygwin. Just
> >>>> because they are in C++. :)
> >>>>
> >>>> The parts of the newlib repo RTEMS uses are under the newlib/
> >>>> subdirectory not the cygwin one. Within that, there is a libc/sys and
> >>>> only libc/sys/rtems is used for RTEMS. The others are for different
> >>>> operating systems. There are a few places with "machine" directory
> >>>> structures. Only the ones for the architecture you are building for
> >>>> is used.
> >>>>
> >>>> As to why NetBSD for libdl, that is because portions of the code
> >>>> originated there.
> >>>>
> >>>> And rtems-libbsd is based on Fre

Re: #4328: New APIs added to POSIX Standard (2021)

[Matthew Joyce]

Dr. Gedare,

Thanks for the info! Ok, I'll make sure to take out the glibc material.

Sincerely,

Matt

On Thu, Apr 1, 2021 at 3:06 PM Gedare Bloom  wrote:
>
> On Thu, Apr 1, 2021 at 6:21 AM Matthew Joyce  wrote:
> >
> > Hi Dr. Joel and Dr. Gedare,
> >
> > I posted my draft proposal on the GSOC 2021 page
> > (https://devel.rtems.org/wiki/GSoC/2021). At your convenience, I would
> > be very grateful for any comments or additional guidance you might
> > have.  Please note, I found implementations of some of the "clock"
> > methods on glibc...does the GNU "Lesser General Public License" meet
> > the intent for what RTEMS can use?
> >
> No. LGPL has a 'relinking' requirement that is not compatible.
>
> > Also, regarding the spawn.h group of methods, do I understand
> > correctly that they've been deliberately left out?  If so, I'm curious
> > if there is anything that would still need to be done there. I noticed
> > in the docs that some methods relating to new processes are supported
> > in an adapted fashion (such as getpid()). Just wondering if there has
> > been discussion on this for spawn so I can cover the bases.
> >
> RTEMS provides conceptually a single-process, multi-threaded, single
> address space. So, any POSIX APIs that relate to multiple process
> management tend to be unsupportable or meaningless. Spawn falls in the
> same category as fork, it doesn't make sense to create a child process
> in a single-process environment.
>
> > Thank you very much for your time!
> >
> > Sincerely,
> >
> > Matt
> >
> > On Thu, Mar 25, 2021 at 2:18 PM Joel Sherrill  wrote:
> > >
> > >
> > >
> > > On Thu, Mar 25, 2021 at 7:14 AM Matthew Joyce  
> > > wrote:
> > >>
> > >> Hi Dr. Joel,
> > >>
> > >> Thanks very much, that's a big help!  Correct, I've been updating the
> > >> spreadsheet as I go along. Ok, now I see that strlcat/strlcpy are used
> > >> in rtems/cpukit and implemented in Newlib.
> > >>
> > >> One additional question, please: I haven't yet looked into the source
> > >> of NetBSD or FreeBSD, but I do see that Newlib already implements
> > >> ppoll (poll.cc), dladdr (dlfcn.cc), pselect (select.cc), and
> > >> sockatmark (net.cc). None of them are defined in the rtems environment
> > >> yet. Is there any reason why the NetBSD/FreeBSD version would be
> > >> preferable to Newlib for these? Or is it just a matter of testing
> > >> what's out there to find what works well in the rtems environment?
> > >
> > >
> > > Without looking at the newlib git repo, I can tell you that the files
> > > you cite are the implementation of those methods for Cygwin. Just
> > > because they are in C++. :)
> > >
> > > The parts of the newlib repo RTEMS uses are under the newlib/
> > > subdirectory not the cygwin one. Within that, there is a libc/sys and
> > > only libc/sys/rtems is used for RTEMS. The others are for different
> > > operating systems. There are a few places with "machine" directory
> > > structures. Only the ones for the architecture you are building for
> > > is used.
> > >
> > > As to why NetBSD for libdl, that is because portions of the code
> > > originated there.
> > >
> > > And rtems-libbsd is based on FreeBSD. It is as close to the FreeBSD
> > > source as we can keep it.
> > >
> > >>
> > >>
> > >> In my proposal I'll take your advice and work on some of the easier
> > >> ones first in order to get the experience and process down.
> > >
> > >
> > > There are tickets for a lot of methods. The rtems-docs repo has the
> > > csv file (e.g. spreadsheet) which tracks RTEMS support against
> > > various standards. The RTEMS POSIX Compliance Guide is generated
> > > from that csv file. Between those, you can find other methods to ask
> > > about. In general, if it is required by the Software Communications
> > > Architecture (SCA) or FACE Technical Standard, then it is a method
> > > someone expected to possibly be used in an embedded system.
> > > SCA is a set of POSIX profiles focused on software defined radios and
> > > the FACE Technical Standard was developed with avionics in mind.
> > >
> > > But any are fair game if they are actually implementable. I don;t think
> > > the Compliance Guide says it yet, but we decided last year that
> > > wo

Re: #4328: New APIs added to POSIX Standard (2021)

[Matthew Joyce]

Hi Dr. Joel and Dr. Gedare,

I posted my draft proposal on the GSOC 2021 page
(https://devel.rtems.org/wiki/GSoC/2021). At your convenience, I would
be very grateful for any comments or additional guidance you might
have.  Please note, I found implementations of some of the "clock"
methods on glibc...does the GNU "Lesser General Public License" meet
the intent for what RTEMS can use?

Also, regarding the spawn.h group of methods, do I understand
correctly that they've been deliberately left out?  If so, I'm curious
if there is anything that would still need to be done there. I noticed
in the docs that some methods relating to new processes are supported
in an adapted fashion (such as getpid()). Just wondering if there has
been discussion on this for spawn so I can cover the bases.

Thank you very much for your time!

Sincerely,

Matt

On Thu, Mar 25, 2021 at 2:18 PM Joel Sherrill  wrote:
>
>
>
> On Thu, Mar 25, 2021 at 7:14 AM Matthew Joyce  wrote:
>>
>> Hi Dr. Joel,
>>
>> Thanks very much, that's a big help!  Correct, I've been updating the
>> spreadsheet as I go along. Ok, now I see that strlcat/strlcpy are used
>> in rtems/cpukit and implemented in Newlib.
>>
>> One additional question, please: I haven't yet looked into the source
>> of NetBSD or FreeBSD, but I do see that Newlib already implements
>> ppoll (poll.cc), dladdr (dlfcn.cc), pselect (select.cc), and
>> sockatmark (net.cc). None of them are defined in the rtems environment
>> yet. Is there any reason why the NetBSD/FreeBSD version would be
>> preferable to Newlib for these? Or is it just a matter of testing
>> what's out there to find what works well in the rtems environment?
>
>
> Without looking at the newlib git repo, I can tell you that the files
> you cite are the implementation of those methods for Cygwin. Just
> because they are in C++. :)
>
> The parts of the newlib repo RTEMS uses are under the newlib/
> subdirectory not the cygwin one. Within that, there is a libc/sys and
> only libc/sys/rtems is used for RTEMS. The others are for different
> operating systems. There are a few places with "machine" directory
> structures. Only the ones for the architecture you are building for
> is used.
>
> As to why NetBSD for libdl, that is because portions of the code
> originated there.
>
> And rtems-libbsd is based on FreeBSD. It is as close to the FreeBSD
> source as we can keep it.
>
>>
>>
>> In my proposal I'll take your advice and work on some of the easier
>> ones first in order to get the experience and process down.
>
>
> There are tickets for a lot of methods. The rtems-docs repo has the
> csv file (e.g. spreadsheet) which tracks RTEMS support against
> various standards. The RTEMS POSIX Compliance Guide is generated
> from that csv file. Between those, you can find other methods to ask
> about. In general, if it is required by the Software Communications
> Architecture (SCA) or FACE Technical Standard, then it is a method
> someone expected to possibly be used in an embedded system.
> SCA is a set of POSIX profiles focused on software defined radios and
> the FACE Technical Standard was developed with avionics in mind.
>
> But any are fair game if they are actually implementable. I don;t think
> the Compliance Guide says it yet, but we decided last year that
> wordexp() is likely not supportable on RTEMS. The newlib
> implementation assumes the presence of a shell with wildcard expansion
> and ability to fork a process.
>
> --joel
>
>>
>>
>> Thank you again for your time!
>>
>> Matt
>>
>> On Wed, Mar 24, 2021 at 5:03 PM Joel Sherrill  wrote:
>> >
>> > Wow! Good work. There is a lot to digest here. Comments interspersed.
>> >
>> > I assume the spreadsheet is updated.
>> >
>> > On Wed, Mar 24, 2021 at 7:38 AM Matthew Joyce  
>> > wrote:
>> >>
>> >> Hi Dr. Joel,
>> >>
>> >> I've gone over the list a few times now and see a few categories shaping 
>> >> up:
>> >>
>> >> 1) Already done (In Newlib source, defined in libc.a):
>> >> a) reallocarray
>> >> b) qsort_r
>> >> c) memmem
>> >> d) strlcat / strlcpy
>> >> d) wcslcat / wcslcpy
>> >> *Out of this group, strlcat and strlcpy also show up in
>> >> src/rtems/cpukit. Why is that?
>> >
>> >
>> > The good news is that we support these. :)
>> >
>> > It looks to me that strlcat and strlcpy are used in cpukit but not 
>> > implemented
>> > there. Where do you think they are implemented

Re: #4328: New APIs added to POSIX Standard (2021)

[Matthew Joyce]

Hi Eshan,

Got it, thanks very much for the explanation! I went ahead and updated
the spreadsheet. It looks like you did an awesome job last year, by
the way :-)

Matt

On Sun, Mar 28, 2021 at 9:57 AM Eshan Dhawan  wrote:
>
>
> > On 28-Mar-2021, at 12:17 PM, Matthew Joyce  wrote:
> >
> > Hi Eshan,
> >
> > Ok, great! Thank you for letting me know. By the way, where will it be
> > implemented when it's patched in? Thanks again and have a great rest
> > of your Sunday.
> Function file : rtems/cpukit/posix
> Tests : testsuite/psxtests
> Since confstr tells about the programming environments supported so it is 
> RTEMS specific.
>
> >
> > Sincerely,
> >
> > Matt
> >
> >> On Sun, Mar 28, 2021 at 6:54 AM Eshan Dhawan  
> >> wrote:
> >>
> >>
> >>>> On 27-Mar-2021, at 1:49 AM, Matthew Joyce  wrote:
> >>>
> >>> Hi Dr. Joel,
> >>>
> >>> I finally built rtems-libbsd and see that pselect and sockatmark are
> >>> both defined there. I went ahead and added a "In rtems-libbsd" column
> >>> in the spreadsheet to reflect that.
> >>>
> >>> With those two defined, it looks like the only methods from the FACE
> >>> 3.0 General Purpose Profile that aren't currently supported are
> >>> confstr() and the  set. Could I ask, what is the thinking on
> >>> those? The man page suggests that spawn was created with embedded
> >>> systems in mind, but I'd guess a conscious decision was made to leave
> >>> them out? How about confstr?
> >>>
> >>> Thank you!
> >>>
> >>> Matt
> >>>
> >> Hi Matt
> >> Confstr code is ready just under styling issues.
> >> So maybe you could count it as Present.
> >>
> >> Thanks
> >> - Eshan
> >>>
> >>>> On Thu, Mar 25, 2021 at 2:18 PM Joel Sherrill  wrote:
> >>>>
> >>>>
> >>>>
> >>>>> On Thu, Mar 25, 2021 at 7:14 AM Matthew Joyce  
> >>>>> wrote:
> >>>>>
> >>>>> Hi Dr. Joel,
> >>>>>
> >>>>> Thanks very much, that's a big help!  Correct, I've been updating the
> >>>>> spreadsheet as I go along. Ok, now I see that strlcat/strlcpy are used
> >>>>> in rtems/cpukit and implemented in Newlib.
> >>>>>
> >>>>> One additional question, please: I haven't yet looked into the source
> >>>>> of NetBSD or FreeBSD, but I do see that Newlib already implements
> >>>>> ppoll (poll.cc), dladdr (dlfcn.cc), pselect (select.cc), and
> >>>>> sockatmark (net.cc). None of them are defined in the rtems environment
> >>>>> yet. Is there any reason why the NetBSD/FreeBSD version would be
> >>>>> preferable to Newlib for these? Or is it just a matter of testing
> >>>>> what's out there to find what works well in the rtems environment?
> >>>>
> >>>>
> >>>> Without looking at the newlib git repo, I can tell you that the files
> >>>> you cite are the implementation of those methods for Cygwin. Just
> >>>> because they are in C++. :)
> >>>>
> >>>> The parts of the newlib repo RTEMS uses are under the newlib/
> >>>> subdirectory not the cygwin one. Within that, there is a libc/sys and
> >>>> only libc/sys/rtems is used for RTEMS. The others are for different
> >>>> operating systems. There are a few places with "machine" directory
> >>>> structures. Only the ones for the architecture you are building for
> >>>> is used.
> >>>>
> >>>> As to why NetBSD for libdl, that is because portions of the code
> >>>> originated there.
> >>>>
> >>>> And rtems-libbsd is based on FreeBSD. It is as close to the FreeBSD
> >>>> source as we can keep it.
> >>>>
> >>>>>
> >>>>>
> >>>>> In my proposal I'll take your advice and work on some of the easier
> >>>>> ones first in order to get the experience and process down.
> >>>>
> >>>>
> >>>> There are tickets for a lot of methods. The rtems-docs repo has the
> >>>> csv file (e.g. spreadsheet) which tracks RTEMS support against
> >>>> various standards. The RTEMS POSIX Compliance Guide is generated
> >>

Re: #4328: New APIs added to POSIX Standard (2021)

[Matthew Joyce]

Hi Eshan,

Ok, great! Thank you for letting me know. By the way, where will it be
implemented when it's patched in? Thanks again and have a great rest
of your Sunday.

Sincerely,

Matt

On Sun, Mar 28, 2021 at 6:54 AM Eshan Dhawan  wrote:
>
>
> > On 27-Mar-2021, at 1:49 AM, Matthew Joyce  wrote:
> >
> > Hi Dr. Joel,
> >
> > I finally built rtems-libbsd and see that pselect and sockatmark are
> > both defined there. I went ahead and added a "In rtems-libbsd" column
> > in the spreadsheet to reflect that.
> >
> > With those two defined, it looks like the only methods from the FACE
> > 3.0 General Purpose Profile that aren't currently supported are
> > confstr() and the  set. Could I ask, what is the thinking on
> > those? The man page suggests that spawn was created with embedded
> > systems in mind, but I'd guess a conscious decision was made to leave
> > them out? How about confstr?
> >
> > Thank you!
> >
> > Matt
> >
> Hi Matt
> Confstr code is ready just under styling issues.
> So maybe you could count it as Present.
>
> Thanks
> - Eshan
> >
> >> On Thu, Mar 25, 2021 at 2:18 PM Joel Sherrill  wrote:
> >>
> >>
> >>
> >>> On Thu, Mar 25, 2021 at 7:14 AM Matthew Joyce  
> >>> wrote:
> >>>
> >>> Hi Dr. Joel,
> >>>
> >>> Thanks very much, that's a big help!  Correct, I've been updating the
> >>> spreadsheet as I go along. Ok, now I see that strlcat/strlcpy are used
> >>> in rtems/cpukit and implemented in Newlib.
> >>>
> >>> One additional question, please: I haven't yet looked into the source
> >>> of NetBSD or FreeBSD, but I do see that Newlib already implements
> >>> ppoll (poll.cc), dladdr (dlfcn.cc), pselect (select.cc), and
> >>> sockatmark (net.cc). None of them are defined in the rtems environment
> >>> yet. Is there any reason why the NetBSD/FreeBSD version would be
> >>> preferable to Newlib for these? Or is it just a matter of testing
> >>> what's out there to find what works well in the rtems environment?
> >>
> >>
> >> Without looking at the newlib git repo, I can tell you that the files
> >> you cite are the implementation of those methods for Cygwin. Just
> >> because they are in C++. :)
> >>
> >> The parts of the newlib repo RTEMS uses are under the newlib/
> >> subdirectory not the cygwin one. Within that, there is a libc/sys and
> >> only libc/sys/rtems is used for RTEMS. The others are for different
> >> operating systems. There are a few places with "machine" directory
> >> structures. Only the ones for the architecture you are building for
> >> is used.
> >>
> >> As to why NetBSD for libdl, that is because portions of the code
> >> originated there.
> >>
> >> And rtems-libbsd is based on FreeBSD. It is as close to the FreeBSD
> >> source as we can keep it.
> >>
> >>>
> >>>
> >>> In my proposal I'll take your advice and work on some of the easier
> >>> ones first in order to get the experience and process down.
> >>
> >>
> >> There are tickets for a lot of methods. The rtems-docs repo has the
> >> csv file (e.g. spreadsheet) which tracks RTEMS support against
> >> various standards. The RTEMS POSIX Compliance Guide is generated
> >> from that csv file. Between those, you can find other methods to ask
> >> about. In general, if it is required by the Software Communications
> >> Architecture (SCA) or FACE Technical Standard, then it is a method
> >> someone expected to possibly be used in an embedded system.
> >> SCA is a set of POSIX profiles focused on software defined radios and
> >> the FACE Technical Standard was developed with avionics in mind.
> >>
> >> But any are fair game if they are actually implementable. I don;t think
> >> the Compliance Guide says it yet, but we decided last year that
> >> wordexp() is likely not supportable on RTEMS. The newlib
> >> implementation assumes the presence of a shell with wildcard expansion
> >> and ability to fork a process.
> >>
> >> --joel
> >>
> >>>
> >>>
> >>> Thank you again for your time!
> >>>
> >>> Matt
> >>>
> >>> On Wed, Mar 24, 2021 at 5:03 PM Joel Sherrill  wrote:
> >>>>
> >>>> Wow! Good work. There is a lot to digest here. Comments intersperse

Re: #4328: New APIs added to POSIX Standard (2021)

[Matthew Joyce]

Hi Dr. Joel,

I finally built rtems-libbsd and see that pselect and sockatmark are
both defined there. I went ahead and added a "In rtems-libbsd" column
in the spreadsheet to reflect that.

With those two defined, it looks like the only methods from the FACE
3.0 General Purpose Profile that aren't currently supported are
confstr() and the  set. Could I ask, what is the thinking on
those? The man page suggests that spawn was created with embedded
systems in mind, but I'd guess a conscious decision was made to leave
them out? How about confstr?

Thank you!

Matt


On Thu, Mar 25, 2021 at 2:18 PM Joel Sherrill  wrote:
>
>
>
> On Thu, Mar 25, 2021 at 7:14 AM Matthew Joyce  wrote:
>>
>> Hi Dr. Joel,
>>
>> Thanks very much, that's a big help!  Correct, I've been updating the
>> spreadsheet as I go along. Ok, now I see that strlcat/strlcpy are used
>> in rtems/cpukit and implemented in Newlib.
>>
>> One additional question, please: I haven't yet looked into the source
>> of NetBSD or FreeBSD, but I do see that Newlib already implements
>> ppoll (poll.cc), dladdr (dlfcn.cc), pselect (select.cc), and
>> sockatmark (net.cc). None of them are defined in the rtems environment
>> yet. Is there any reason why the NetBSD/FreeBSD version would be
>> preferable to Newlib for these? Or is it just a matter of testing
>> what's out there to find what works well in the rtems environment?
>
>
> Without looking at the newlib git repo, I can tell you that the files
> you cite are the implementation of those methods for Cygwin. Just
> because they are in C++. :)
>
> The parts of the newlib repo RTEMS uses are under the newlib/
> subdirectory not the cygwin one. Within that, there is a libc/sys and
> only libc/sys/rtems is used for RTEMS. The others are for different
> operating systems. There are a few places with "machine" directory
> structures. Only the ones for the architecture you are building for
> is used.
>
> As to why NetBSD for libdl, that is because portions of the code
> originated there.
>
> And rtems-libbsd is based on FreeBSD. It is as close to the FreeBSD
> source as we can keep it.
>
>>
>>
>> In my proposal I'll take your advice and work on some of the easier
>> ones first in order to get the experience and process down.
>
>
> There are tickets for a lot of methods. The rtems-docs repo has the
> csv file (e.g. spreadsheet) which tracks RTEMS support against
> various standards. The RTEMS POSIX Compliance Guide is generated
> from that csv file. Between those, you can find other methods to ask
> about. In general, if it is required by the Software Communications
> Architecture (SCA) or FACE Technical Standard, then it is a method
> someone expected to possibly be used in an embedded system.
> SCA is a set of POSIX profiles focused on software defined radios and
> the FACE Technical Standard was developed with avionics in mind.
>
> But any are fair game if they are actually implementable. I don;t think
> the Compliance Guide says it yet, but we decided last year that
> wordexp() is likely not supportable on RTEMS. The newlib
> implementation assumes the presence of a shell with wildcard expansion
> and ability to fork a process.
>
> --joel
>
>>
>>
>> Thank you again for your time!
>>
>> Matt
>>
>> On Wed, Mar 24, 2021 at 5:03 PM Joel Sherrill  wrote:
>> >
>> > Wow! Good work. There is a lot to digest here. Comments interspersed.
>> >
>> > I assume the spreadsheet is updated.
>> >
>> > On Wed, Mar 24, 2021 at 7:38 AM Matthew Joyce  
>> > wrote:
>> >>
>> >> Hi Dr. Joel,
>> >>
>> >> I've gone over the list a few times now and see a few categories shaping 
>> >> up:
>> >>
>> >> 1) Already done (In Newlib source, defined in libc.a):
>> >> a) reallocarray
>> >> b) qsort_r
>> >> c) memmem
>> >> d) strlcat / strlcpy
>> >> d) wcslcat / wcslcpy
>> >> *Out of this group, strlcat and strlcpy also show up in
>> >> src/rtems/cpukit. Why is that?
>> >
>> >
>> > The good news is that we support these. :)
>> >
>> > It looks to me that strlcat and strlcpy are used in cpukit but not 
>> > implemented
>> > there. Where do you think they are implemented.
>> >
>> > This is a good example where a source code browser is helpful. grep can
>> > often answer the question but a source code browser can be easier. 
>> > Personally,
>> > I use cscope but that is exceedingly old school. Any modern IDE should be
>&g

Re: #4328: New APIs added to POSIX Standard (2021)

[Matthew Joyce]

Oh wow. That makes so much more sense now! Thanks very much for the
clarification!

Sincerely,

Matt

On Thu, Mar 25, 2021 at 2:18 PM Joel Sherrill  wrote:
>
>
>
> On Thu, Mar 25, 2021 at 7:14 AM Matthew Joyce  wrote:
>>
>> Hi Dr. Joel,
>>
>> Thanks very much, that's a big help!  Correct, I've been updating the
>> spreadsheet as I go along. Ok, now I see that strlcat/strlcpy are used
>> in rtems/cpukit and implemented in Newlib.
>>
>> One additional question, please: I haven't yet looked into the source
>> of NetBSD or FreeBSD, but I do see that Newlib already implements
>> ppoll (poll.cc), dladdr (dlfcn.cc), pselect (select.cc), and
>> sockatmark (net.cc). None of them are defined in the rtems environment
>> yet. Is there any reason why the NetBSD/FreeBSD version would be
>> preferable to Newlib for these? Or is it just a matter of testing
>> what's out there to find what works well in the rtems environment?
>
>
> Without looking at the newlib git repo, I can tell you that the files
> you cite are the implementation of those methods for Cygwin. Just
> because they are in C++. :)
>
> The parts of the newlib repo RTEMS uses are under the newlib/
> subdirectory not the cygwin one. Within that, there is a libc/sys and
> only libc/sys/rtems is used for RTEMS. The others are for different
> operating systems. There are a few places with "machine" directory
> structures. Only the ones for the architecture you are building for
> is used.
>
> As to why NetBSD for libdl, that is because portions of the code
> originated there.
>
> And rtems-libbsd is based on FreeBSD. It is as close to the FreeBSD
> source as we can keep it.
>
>>
>>
>> In my proposal I'll take your advice and work on some of the easier
>> ones first in order to get the experience and process down.
>
>
> There are tickets for a lot of methods. The rtems-docs repo has the
> csv file (e.g. spreadsheet) which tracks RTEMS support against
> various standards. The RTEMS POSIX Compliance Guide is generated
> from that csv file. Between those, you can find other methods to ask
> about. In general, if it is required by the Software Communications
> Architecture (SCA) or FACE Technical Standard, then it is a method
> someone expected to possibly be used in an embedded system.
> SCA is a set of POSIX profiles focused on software defined radios and
> the FACE Technical Standard was developed with avionics in mind.
>
> But any are fair game if they are actually implementable. I don;t think
> the Compliance Guide says it yet, but we decided last year that
> wordexp() is likely not supportable on RTEMS. The newlib
> implementation assumes the presence of a shell with wildcard expansion
> and ability to fork a process.
>
> --joel
>
>>
>>
>> Thank you again for your time!
>>
>> Matt
>>
>> On Wed, Mar 24, 2021 at 5:03 PM Joel Sherrill  wrote:
>> >
>> > Wow! Good work. There is a lot to digest here. Comments interspersed.
>> >
>> > I assume the spreadsheet is updated.
>> >
>> > On Wed, Mar 24, 2021 at 7:38 AM Matthew Joyce  
>> > wrote:
>> >>
>> >> Hi Dr. Joel,
>> >>
>> >> I've gone over the list a few times now and see a few categories shaping 
>> >> up:
>> >>
>> >> 1) Already done (In Newlib source, defined in libc.a):
>> >> a) reallocarray
>> >> b) qsort_r
>> >> c) memmem
>> >> d) strlcat / strlcpy
>> >> d) wcslcat / wcslcpy
>> >> *Out of this group, strlcat and strlcpy also show up in
>> >> src/rtems/cpukit. Why is that?
>> >
>> >
>> > The good news is that we support these. :)
>> >
>> > It looks to me that strlcat and strlcpy are used in cpukit but not 
>> > implemented
>> > there. Where do you think they are implemented.
>> >
>> > This is a good example where a source code browser is helpful. grep can
>> > often answer the question but a source code browser can be easier. 
>> > Personally,
>> > I use cscope but that is exceedingly old school. Any modern IDE should be
>> > helpful.
>> >
>> >>
>> >> 2) Not done yet (Do not show up in Newlib source or RTEMS):
>> >> a) getlocalename_l
>> >> b) posix_getdents
>> >> c) sem_clockwait
>> >> d) sig2str / str2sig
>> >>
>> >> 3) Not in Newlib; Referenced in RTEMS but hidden behind #ifdef:
>> >> a) pthread_cond_clockwait
>> >> (rtems/6/lib/gcc/sparc-rtems6/10.2.1/i

Re: #4328: New APIs added to POSIX Standard (2021)

[Matthew Joyce]

Hi Dr. Joel,

Thanks very much, that's a big help!  Correct, I've been updating the
spreadsheet as I go along. Ok, now I see that strlcat/strlcpy are used
in rtems/cpukit and implemented in Newlib.

One additional question, please: I haven't yet looked into the source
of NetBSD or FreeBSD, but I do see that Newlib already implements
ppoll (poll.cc), dladdr (dlfcn.cc), pselect (select.cc), and
sockatmark (net.cc). None of them are defined in the rtems environment
yet. Is there any reason why the NetBSD/FreeBSD version would be
preferable to Newlib for these? Or is it just a matter of testing
what's out there to find what works well in the rtems environment?

In my proposal I'll take your advice and work on some of the easier
ones first in order to get the experience and process down.

Thank you again for your time!

Matt

On Wed, Mar 24, 2021 at 5:03 PM Joel Sherrill  wrote:
>
> Wow! Good work. There is a lot to digest here. Comments interspersed.
>
> I assume the spreadsheet is updated.
>
> On Wed, Mar 24, 2021 at 7:38 AM Matthew Joyce  wrote:
>>
>> Hi Dr. Joel,
>>
>> I've gone over the list a few times now and see a few categories shaping up:
>>
>> 1) Already done (In Newlib source, defined in libc.a):
>> a) reallocarray
>> b) qsort_r
>> c) memmem
>> d) strlcat / strlcpy
>> d) wcslcat / wcslcpy
>> *Out of this group, strlcat and strlcpy also show up in
>> src/rtems/cpukit. Why is that?
>
>
> The good news is that we support these. :)
>
> It looks to me that strlcat and strlcpy are used in cpukit but not implemented
> there. Where do you think they are implemented.
>
> This is a good example where a source code browser is helpful. grep can
> often answer the question but a source code browser can be easier. Personally,
> I use cscope but that is exceedingly old school. Any modern IDE should be
> helpful.
>
>>
>> 2) Not done yet (Do not show up in Newlib source or RTEMS):
>> a) getlocalename_l
>> b) posix_getdents
>> c) sem_clockwait
>> d) sig2str / str2sig
>>
>> 3) Not in Newlib; Referenced in RTEMS but hidden behind #ifdef:
>> a) pthread_cond_clockwait
>> (rtems/6/lib/gcc/sparc-rtems6/10.2.1/include/c++/condition_variable)
>> b) pthread_mutex_clocklock
>> (rtems/6/lib/gcc/sparc-rtems6/10.2.1/include/c++/mutex)
>> c) pthread_rwlock_clockrdlock
>> (rtems/6/lib/gcc/sparc-rtems6/10.2.1/include/c++/shared_mutex)
>> c) pthread_rwlock_clockwrlock
>> (rtems/6/lib/gcc/sparc-rtems6/10.2.1/include/c++/shared_mutex)
>> *It looks like some groundwork was done, but the methods are not yet 
>> supported.
>
>
> The paths you point to are C++ files that would implement C++ features
> using the available POSIX services. So they are users, not providers.
>
> All of the pthread services related to these are implemented in
> cpukit/posix/src. I think you can configure a clock for all these now
> to be used by detailed on wait and timedwait calls. My understanding
> is that these would let you use a specific clock on a per blocking call
> basis.
>
> First question is which clocks are intended to be supported.
>
> Second is the pattern of picking which timeout queue to go on when
> now it is coded to let you pick one which is used for the life of the object.
>
>>
>> 4) Misc (In Newlib source, not defined in libc.a, appear in RTEMS in
>> various ways)
>> a) getentropy (an alternate version is defined in RTEMS librtemsbsd.a,
>> in src/rtems/bsps/shared/dev/getentropy/getentropy-cpucounter.c. The
>> comments note that it is not cryptographically secure, so it may not
>> fit the bill for the getentropy() mentioned in the Open Group
>> document)
>
>
> I am far from a cryptography expert but this looks like a case where
> this method would be considered supported with the disclaimer that
> the quality of the entropy value depends on the BSP. If the user has
> specific requirements, they will need to verify the implementation
> used by the BSP by default is appropriate.
>
>>
>> b) ppoll (appears in rtems/6/share/gdb/syscalls)
>
>
> You need to be more careful with the grep. These again are in the
> installed tools and in this case, they appear in an XML file. Referenced
> but not implemented.
>
> ppoll() will need to come from rtems-libbsd. The required system call
> is included but disabled currently. AFAIK this means it is possible to
> provide this but that would require a more detailed discussion in case
> some underlying capability is missing. Chris Johns and Sebastian
> Huber would be the ones to guide here.
>
> Ruling: Likely possible.
>
>>
>> c) dladdr (appears in rtems/cpukit but not defined)
>
>

Re: #4328: New APIs added to POSIX Standard (2021)

[Matthew Joyce]

Hi Dr. Joel,

I've gone over the list a few times now and see a few categories shaping up:

1) Already done (In Newlib source, defined in libc.a):
a) reallocarray
b) qsort_r
c) memmem
d) strlcat / strlcpy
d) wcslcat / wcslcpy
*Out of this group, strlcat and strlcpy also show up in
src/rtems/cpukit. Why is that?

2) Not done yet (Do not show up in Newlib source or RTEMS):
a) getlocalename_l
b) posix_getdents
c) sem_clockwait
d) sig2str / str2sig

3) Not in Newlib; Referenced in RTEMS but hidden behind #ifdef:
a) pthread_cond_clockwait
(rtems/6/lib/gcc/sparc-rtems6/10.2.1/include/c++/condition_variable)
b) pthread_mutex_clocklock
(rtems/6/lib/gcc/sparc-rtems6/10.2.1/include/c++/mutex)
c) pthread_rwlock_clockrdlock
(rtems/6/lib/gcc/sparc-rtems6/10.2.1/include/c++/shared_mutex)
c) pthread_rwlock_clockwrlock
(rtems/6/lib/gcc/sparc-rtems6/10.2.1/include/c++/shared_mutex)
*It looks like some groundwork was done, but the methods are not yet supported.

4) Misc (In Newlib source, not defined in libc.a, appear in RTEMS in
various ways)
a) getentropy (an alternate version is defined in RTEMS librtemsbsd.a,
in src/rtems/bsps/shared/dev/getentropy/getentropy-cpucounter.c. The
comments note that it is not cryptographically secure, so it may not
fit the bill for the getentropy() mentioned in the Open Group
document)
b) ppoll (appears in rtems/6/share/gdb/syscalls)
c) dladdr (appears in rtems/cpukit but not defined)

5) Others?
It looks like there was work done on methods like sockatmark and
pselect, but I don't see them supported as yet. Should those be added
to the list or are they still being worked on?

As you suggested, I'll look into NetBSD for dladdr and do some digging
on the implementation of the other outstanding methods. You mentioned
that the "clock" ones have to be strictly added to rtems/cpukit, but
the references I found above are all in lib/gcc/sparc-rtems6/10.2.1.
Why is that the case and what is 10.2.1? Also, I'm not sure what to
make of getentropy and ppoll based on what I found above...at your
convenience could you please advise?

Thank you very much!

Matt




On Sun, Mar 21, 2021 at 6:38 PM Joel Sherrill  wrote:
>
>
>
> On Sun, Mar 21, 2021 at 2:28 AM Matthew Joyce  wrote:
>>
>> Gentlemen,
>>
>> Awesome, thanks!  I see how that works now...I'll give it a thorough
>> look tomorrow and will update the spreadsheet accordingly. I'll pipe
>> back up when I have a more accurate look of what's currently there.
>
>
> Knowing what doesn't have to be done is the first step. (rtems, newlib, and 
> libbsd)
>
> I'd be prone to look for things that are easy to add first.
>
> Some may not be implementable on RTEMS due to only supporting a
> single process and no virtual memory. If you have doubts on whether it
> is possible to support a specific method, speak up and let's try to decide.
>
> Then find upstream places for an implementation where possible. I suspect
> all the new "clock" methods will require discussion on an implementation
> pattern but those must strictly be added to rtems/cpukit with tests and
> documentation. At least I can throw you that much. :)
>
>>
>> Thanks again and have a great Sunday!
>>
>> Matt
>>
>> On Fri, Mar 19, 2021 at 8:27 PM Joel Sherrill  wrote:
>> >
>> >
>> >
>> > On Fri, Mar 19, 2021 at 1:08 PM Gedare Bloom  wrote:
>> >>
>> >> On Fri, Mar 19, 2021 at 11:16 AM Matthew Joyce  
>> >> wrote:
>> >> >
>> >> > Dr. Joel,
>> >> >
>> >> > Thanks very much...I'll keep working to get a sense of what goes
>> >> > where! In the meantime, where can I look to get the ground truth of
>> >> > which methods are "in RTEMS" as opposed to those in newlib?
>> >> >
>> >> There is only one ground truth:
>> >> git://git.rtems.org/rtems.git
>> >>
>> >> And for newlib
>> >>
>> >> git://sourceware.org/git/newlib-cygwin.git
>> >>
>> >> That said, searching for the function name symbols in compiled
>> >> libraries is a good first step to rule out newlib. Then, you can
>> >> 'grep' the RTEMS source code for the function names to see if they
>> >> exist there.
>> >
>> >
>> > rtems/cpukit to be specitic. It won't be implemented anywhere else.
>> >
>> > And clearly we both have forgotten that networking APIs are in the
>> > rtems-libbsd repository.
>> >
>> > https://git.rtems.org/rtems-libbsd/
>> >
>> > I suspect ppoll() might already be in there. Or at least supported by
>> > FreeBSD.
>> >
>> > You should clone everything a

Re: #4328: New APIs added to POSIX Standard (2021)

[Matthew Joyce]

Gentlemen,

Awesome, thanks!  I see how that works now...I'll give it a thorough
look tomorrow and will update the spreadsheet accordingly. I'll pipe
back up when I have a more accurate look of what's currently there.
Thanks again and have a great Sunday!

Matt

On Fri, Mar 19, 2021 at 8:27 PM Joel Sherrill  wrote:
>
>
>
> On Fri, Mar 19, 2021 at 1:08 PM Gedare Bloom  wrote:
>>
>> On Fri, Mar 19, 2021 at 11:16 AM Matthew Joyce  wrote:
>> >
>> > Dr. Joel,
>> >
>> > Thanks very much...I'll keep working to get a sense of what goes
>> > where! In the meantime, where can I look to get the ground truth of
>> > which methods are "in RTEMS" as opposed to those in newlib?
>> >
>> There is only one ground truth:
>> git://git.rtems.org/rtems.git
>>
>> And for newlib
>>
>> git://sourceware.org/git/newlib-cygwin.git
>>
>> That said, searching for the function name symbols in compiled
>> libraries is a good first step to rule out newlib. Then, you can
>> 'grep' the RTEMS source code for the function names to see if they
>> exist there.
>
>
> rtems/cpukit to be specitic. It won't be implemented anywhere else.
>
> And clearly we both have forgotten that networking APIs are in the
> rtems-libbsd repository.
>
> https://git.rtems.org/rtems-libbsd/
>
> I suspect ppoll() might already be in there. Or at least supported by
> FreeBSD.
>
> You should clone everything and grep the sources. newlib already has
> qsort_r. This is the nm I used:
>
> $ ~/rtems-work/tools/6/bin/sparc-rtems6-nm 
> ~/rtems-work/tools/6/sparc-rtems6/lib/libc.a | grep qsort_r
> lib_a-bsd_qsort_r.o:
>  T __bsd_qsort_r
> lib_a-qsort_r.o:
>  T qsort_r
>
> Notice the last line has "T qsort_r" which says it is defined.
>
> grep -r in the newlib source shows it is in ./libc/search/qsort_r.c
>
> dladdr() looks to be prototyped in RTEMS but hidden behind an ifdef like it
> wasn't ported from NetBSD so that looks possible. It is in rtems.
>
> Those two examples should help you figure out why you missed
> finding some things that were implemented.
>
> I need to figure out what this next POSIX version is to be called
> so I can update the tracking spreadsheet that generates the RTEMS
> POSIX Compliance Guide, :)
>
> --joel
>>
>>
>> > Thanks again!
>> >
>> > Matt
>> >
>> > On Fri, Mar 19, 2021 at 1:58 PM Joel Sherrill  wrote:
>> > >
>> > > Keep devel@ on the list. :)
>> > >
>> > > On Fri, Mar 19, 2021 at 7:51 AM Matthew Joyce  
>> > > wrote:
>> > >>
>> > >> Sir,
>> > >>
>> > >> Thank you for the link! I see that you're right, those last four are
>> > >> in newlib, plus memmem(). I updated those in the Google Sheet.
>> > >>
>> > >> Now I see the newlib part, but where are you referring to specifically
>> > >> when you say RTEMS, as in "POSIX support comes from a mix of RTEMS and
>> > >> newlib"?
>> > >
>> > >
>> > > POSIX is a HUGE HUGE standard and references other standards. One
>> > > it references and pulls in is the C99 Standard C Library which is libc 
>> > > and
>> > > libm. RTEMS mostly does not implement this functionality and relies on
>> > > another open source project for those APIs. Newlib is an open source
>> > > C Library used by RTEMS, Cygwin, and most embedded systems GNU tools
>> > > chains.
>> > >
>> > > Most of the POSIX header files with RTEMS are actually in Newlib even
>> > > if they originated with RTEMS. Many are shared with Cygwin.
>> > >
>> > > So methods like the string, memory, and *printf come from Newlib since 
>> > > they
>> > > are in C99. We provide POSIX like threading, signals, core file access, 
>> > > and
>> > > much more.
>> > >
>> > > It's a complementary relationship but it takes a bit to figure out when
>> > > something should be in one or the other. The line gets blurred at times.
>> > >
>> > > Say you added a new CPU architecture implementation of a math
>> > > method (like Eshan did last year), then it goes in newlib. But he also
>> > > added some POSIX methods which go in RTEMS. In either case,
>> > > we like tests for them in RTEMS to show they work in our environment.
>> > >
>> > > --joel
>> > >
>> > >
>> > 

Re: #4328: New APIs added to POSIX Standard (2021)

[Matthew Joyce]

Dr. Joel,

Thanks very much...I'll keep working to get a sense of what goes
where! In the meantime, where can I look to get the ground truth of
which methods are "in RTEMS" as opposed to those in newlib?

Thanks again!

Matt

On Fri, Mar 19, 2021 at 1:58 PM Joel Sherrill  wrote:
>
> Keep devel@ on the list. :)
>
> On Fri, Mar 19, 2021 at 7:51 AM Matthew Joyce  wrote:
>>
>> Sir,
>>
>> Thank you for the link! I see that you're right, those last four are
>> in newlib, plus memmem(). I updated those in the Google Sheet.
>>
>> Now I see the newlib part, but where are you referring to specifically
>> when you say RTEMS, as in "POSIX support comes from a mix of RTEMS and
>> newlib"?
>
>
> POSIX is a HUGE HUGE standard and references other standards. One
> it references and pulls in is the C99 Standard C Library which is libc and
> libm. RTEMS mostly does not implement this functionality and relies on
> another open source project for those APIs. Newlib is an open source
> C Library used by RTEMS, Cygwin, and most embedded systems GNU tools
> chains.
>
> Most of the POSIX header files with RTEMS are actually in Newlib even
> if they originated with RTEMS. Many are shared with Cygwin.
>
> So methods like the string, memory, and *printf come from Newlib since they
> are in C99. We provide POSIX like threading, signals, core file access, and
> much more.
>
> It's a complementary relationship but it takes a bit to figure out when
> something should be in one or the other. The line gets blurred at times.
>
> Say you added a new CPU architecture implementation of a math
> method (like Eshan did last year), then it goes in newlib. But he also
> added some POSIX methods which go in RTEMS. In either case,
> we like tests for them in RTEMS to show they work in our environment.
>
> --joel
>
>
>
>>
>> Thanks again!
>>
>> Matt
>>
>> On Fri, Mar 19, 2021 at 1:13 PM Joel Sherrill  wrote:
>> >
>> >
>> >
>> > On Fri, Mar 19, 2021, 6:40 AM Joel Sherrill  wrote:
>> >>
>> >>
>> >>
>> >> On Fri, Mar 19, 2021, 5:48 AM Matthew Joyce  wrote:
>> >>>
>> >>> https://docs.google.com/spreadsheets/d/1reCNOIZC5JTwQENgl-hvG8THfQqNtlUDVy_07PYodic/edit?usp=sharing
>> >>>
>> >>> Hello,
>> >>>
>> >>> As suggested by Dr. Sherril, I've taken an initial look through this
>> >>> document https://www.opengroup.org/austin/docs/austin_1110.pdf and
>> >>> added the new methods  to a Googe Sheet, linked above.
>> >>>
>> >>> None of them appear to be in the RTEMS POSIX API Users Guide, but
>> >>> maybe that's not the right place to look. I'll stand by for your
>> >>> feedback regarding what's possible / desirable to add to RTEMS.
>> >>
>> >>
>> >> It is possible they are in our C Library or Math Library.  Or just not in 
>> >> the manual. The POSIX manual tends to be sparse since you can always use 
>> >> man pages or the POSIX standard.
>> >>
>> >> Since you have RTEMS and tools built. Find one of the libc.a and libm.a 
>> >> files in the tools install and librtemscpu.a in the RTEMS build or 
>> >> install. Then try a command something like this:
>> >>
>> >> CPU-rtems6-nm LIBRARY | grep SYMBOL
>> >>
>> >> If you see it list with T then it is in the text section and there.
>> >
>> >
>> > Following up, I initially answered from my phone and didn't look at 
>> > source.  I am still on my phone but looked through the list and think the 
>> > last four methods are probably the only ones currently supported.
>> >
>> > https://sourceware.org/git/?p=newlib-cygwin.git;a=tree;f=newlib/libc/string;h=ceeec602cdd0e6b5c6b002b741bda9b41da4e441;hb=HEAD
>> >
>> > POSIX support comes from a mix of RTEMS and newlib. That's key to this 
>> > type of project.
>> >
>> > --joel
>> >>
>> >>
>> >>
>> >>>
>> >>> Thanks very much for your time!
>> >>>
>> >>> Sincerely,
>> >>>
>> >>> Matt
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

#4328: New APIs added to POSIX Standard (2021)

[Matthew Joyce]

https://docs.google.com/spreadsheets/d/1reCNOIZC5JTwQENgl-hvG8THfQqNtlUDVy_07PYodic/edit?usp=sharing

Hello,

As suggested by Dr. Sherril, I've taken an initial look through this
document https://www.opengroup.org/austin/docs/austin_1110.pdf and
added the new methods  to a Googe Sheet, linked above.

None of them appear to be in the RTEMS POSIX API Users Guide, but
maybe that's not the right place to look. I'll stand by for your
feedback regarding what's possible / desirable to add to RTEMS.

Thanks very much for your time!

Sincerely,

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

Re: GSoC: Matt Joyce Introduction

[Matthew Joyce]

Sir,

Thanks very much, that sounds great! I'll start a new thread with the
initial Google Sheet.

Sincerely,

Matt

On Thu, Mar 18, 2021 at 5:31 PM Joel Sherrill  wrote:
>
>
>
> On Wed, Mar 17, 2021 at 10:50 AM Gedare Bloom  wrote:
>>
>> Hi Matt,
>>
>> On Wed, Mar 17, 2021 at 6:18 AM Matthew Joyce  wrote:
>> >
>> > Hello RTEMS Community!
>> >
>> > My name is Matt, I’m a former US Army infantry officer, now back in school 
>> > pursuing a second bachelor’s in Computer Science at Oregon State 
>> > University.
>> >
>> > I am new to open source, but I am just completing my second (elective) 
>> > operating systems course and have a class in x86 assembly language under 
>> > my belt. I’m starting my first class in embedded programming at the end of 
>> > the month. (I’m excited!)
>> >
>> Welcome! That sounds like a good baseline to start with RTEMS from.
>
>
> +1 RTEMS as GSoC should be a good pairing with that class.
>>
>>
>> >
>> >
>> > Based on the long-term participation of previous years’ GSoC students, I 
>> > see that this community is committed to stewarding the project into the 
>> > future. And I see that the work you do is literally out there among the 
>> > stars. That is what I’d call a legacy! I know that I could learn so much 
>> > from the community, and hopefully, with a lot of sweat, contribute 
>> > something as well.
>> >
>> > One project in which I’m interested is #4328: “New APIs Added to POSIX 
>> > Standard (2021)”. I would be grateful if someone could help me understand 
>> > the current state of this effort and where it fits into the greater “POSIX 
>> > Compliance” effort (#2966). I notice in the “Small Projects” section there 
>> > is a task to flesh out the RTEMS POSIX User’s Guide. I thought that this 
>> > might be a good way for me to build up my understanding of RTEMS, prepare 
>> > me to better work on 4328, and add something along the way. Is that 
>> > something that would be helpful?
>> >
>>
>> Joel should be able to provide guidance on both fronts. Improving the
>> documentation is always helpful. The POSIX code improvements are often
>> a good, incremental coding activity.
>
>
> As the 2021 in the title implies, this is quite new. The POSIX working group
> just announced the draft of what should be coming this month. The first
> step is to go through the document linked and see what methods are added
> (or deleted). It has change bars and I think you can just search for "+" to
> find text additions.
>
> (1) Make a master list of what is added. A Google Sheet is nice for this.
> (2) With help, we figure out what already is in RTEMS and our C Library.
>
> Those two provide a baseline of what could be picked from as new methods
> to add. For that subset, we will work together to see what you could port
> from FreeBSD, NetBSD, or somewhere else with a permissive license;
> what cannot be implemented on RTEMS, and what has to be written from
> scratch. Some of the possible will be the GSoC project you propose.
>
> Gedare is right about it being incremental. There are usually related
> sets of methods and you add a set, test it, put the patch(es) out for
> review, repeat. Based on Eshan's experience last year, you can easily
> have a handful of method sets at different stages. You will get feedback
> and have to make updates. Some patches go to the newlib C Library
> we use and those sometimes get comments we just don't make because
> we usually don't catch impact on non-RTEMS targets.
>
> Anyway, this is a good project and I'm the primary mentor for these
> POSIX tasks..
>
> --joel
>
>>
>>
>> >
>> >
>> > It’s nice to “meet” you all and I look forward to hearing back from you!
>> >
>>
>> Great. One thing you might consider is to use plain-text mode instead
>> of HTML/rich-text editor. It will make your emails easier to reply to
>> in threaded context.
>>
>> Gedare
>>
>> >
>> >
>> > Sincerely,
>> >
>> > Matt
>> >
>> >
>> >
>> >
>> >
>> > ___
>> > 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: GSoC: Matt Joyce Introduction

[Matthew Joyce]

Hi Gedare,

Thank you very much for the welcome! Will do on the plain-text.
Hopefully this is better.

Hello Dr. Sherrill,

I’ll stand by for your guidance at your convenience. I’d be happy to
recommend updates to the POSIX Compliance Guide and API Guide if I
can. Based on Ehsan Dhawan’s notes from GSoC 2020, I suspect some of
the methods marked as “not supported” in the docs have already been
added (such as from fenv.h, for example). But I’m not sure where I
should look to confirm.

Thank you very much!

Sincerely,

Matt





On Wed, Mar 17, 2021 at 4:50 PM Gedare Bloom  wrote:
>
> Hi Matt,
>
> On Wed, Mar 17, 2021 at 6:18 AM Matthew Joyce  wrote:
> >
> > Hello RTEMS Community!
> >
> > My name is Matt, I’m a former US Army infantry officer, now back in school 
> > pursuing a second bachelor’s in Computer Science at Oregon State University.
> >
> > I am new to open source, but I am just completing my second (elective) 
> > operating systems course and have a class in x86 assembly language under my 
> > belt. I’m starting my first class in embedded programming at the end of the 
> > month. (I’m excited!)
> >
> Welcome! That sounds like a good baseline to start with RTEMS from.
>
> >
> >
> > Based on the long-term participation of previous years’ GSoC students, I 
> > see that this community is committed to stewarding the project into the 
> > future. And I see that the work you do is literally out there among the 
> > stars. That is what I’d call a legacy! I know that I could learn so much 
> > from the community, and hopefully, with a lot of sweat, contribute 
> > something as well.
> >
> > One project in which I’m interested is #4328: “New APIs Added to POSIX 
> > Standard (2021)”. I would be grateful if someone could help me understand 
> > the current state of this effort and where it fits into the greater “POSIX 
> > Compliance” effort (#2966). I notice in the “Small Projects” section there 
> > is a task to flesh out the RTEMS POSIX User’s Guide. I thought that this 
> > might be a good way for me to build up my understanding of RTEMS, prepare 
> > me to better work on 4328, and add something along the way. Is that 
> > something that would be helpful?
> >
>
> Joel should be able to provide guidance on both fronts. Improving the
> documentation is always helpful. The POSIX code improvements are often
> a good, incremental coding activity.
>
> >
> >
> > It’s nice to “meet” you all and I look forward to hearing back from you!
> >
>
> Great. One thing you might consider is to use plain-text mode instead
> of HTML/rich-text editor. It will make your emails easier to reply to
> in threaded context.
>
> Gedare
>
> >
> >
> > Sincerely,
> >
> > Matt
> >
> >
> >
> >
> >
> > ___
> > 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

GSoC: Matt Joyce Introduction

[Matthew Joyce]

Hello RTEMS Community!



My name is Matt, I’m a former US Army infantry officer, now back in school
pursuing a second bachelor’s in Computer Science at Oregon State
University.



I am new to open source, but I am just completing my second (elective)
operating systems course and have a class in x86 assembly language under my
belt. I’m starting my first class in embedded programming at the end of the
month. (I’m excited!)



Based on the long-term participation of previous years’ GSoC students, I
see that this community is committed to stewarding the project into the
future. And I see that the work you do is literally out there among the
stars. That is what I’d call a legacy! I know that I could learn so much
from the community, and hopefully, with a lot of sweat, contribute
something as well.



One project in which I’m interested is #4328: “New APIs Added to POSIX
Standard (2021)”. I would be grateful if someone could help me understand
the current state of this effort and where it fits into the greater “POSIX
Compliance” effort (#2966). I notice in the “Small Projects” section there
is a task to flesh out the RTEMS POSIX User’s Guide. I thought that this
might be a good way for me to build up my understanding of RTEMS, prepare
me to better work on 4328, and add something along the way. Is that
something that would be helpful?



It’s nice to “meet” you all and I look forward to hearing back from you!



Sincerely,

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

[Screenshot] Matt Joyce GSOC Hello World Patch

[Matthew Joyce]

Hello RTEMS Community,

Please find my attached screenshot for the GSOC Hello World introduction.
Thank you again for your time!

Sincerely,

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