Re: Blockers for Cutover to Waf

[Sebastian Huber]

Hello Joel,

On 28/10/2020 15:25, Joel Sherrill wrote:

Hi

I didn't want to hijack the greth thread with this but there are open 
wafblocker issues which prevent the cutover to waf.


https://devel.rtems.org/query?status=accepted&status=assigned&status=new&status=reopened&keywords=~wafblocker&group=status&col=id&col=summary&col=owner&col=type&col=priority&col=component&col=version&order=priority 



These need to be addressed.


the only blocking issue from my point of view is

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

for which I provided a patch

https://lists.rtems.org/pipermail/devel/2020-November/063024.html

All other issues can be addressed after the removal of the old build 
system. Maintaining the old build system needs extra time which cannot 
be used to address these issues for example.


--
embedded brains GmbH
Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
Phone: +49-89-18 94 741 - 16
Fax:   +49-89-18 94 741 - 08
PGP: Public key available on request.

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

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

[PATCH 4/4] sparc: Add SPARC_INTERRUPT_SOURCE_TO_TRAP()

[Sebastian Huber]

Update #4171.
---
 bsps/sparc/erc32/include/erc32.h   | 2 +-
 bsps/sparc/leon2/include/leon.h| 2 +-
 bsps/sparc/leon3/include/leon.h| 2 +-
 cpukit/score/cpu/sparc/include/rtems/score/sparc.h | 9 +
 4 files changed, 12 insertions(+), 3 deletions(-)

diff --git a/bsps/sparc/erc32/include/erc32.h b/bsps/sparc/erc32/include/erc32.h
index 6d79772cc7..a677b13d25 100644
--- a/bsps/sparc/erc32/include/erc32.h
+++ b/bsps/sparc/erc32/include/erc32.h
@@ -83,7 +83,7 @@ extern "C" {
  *significant nibble of the trap type.
  */
 
-#define ERC32_TRAP_TYPE( _source ) SPARC_ASYNCHRONOUS_TRAP((_source) + 0x10)
+#define ERC32_TRAP_TYPE( _source ) SPARC_INTERRUPT_SOURCE_TO_TRAP( _source )
 
 #define ERC32_TRAP_SOURCE( _trap ) SPARC_INTERRUPT_TRAP_TO_SOURCE( _trap )
 
diff --git a/bsps/sparc/leon2/include/leon.h b/bsps/sparc/leon2/include/leon.h
index 1d58aa7d39..fc90e1f7e6 100644
--- a/bsps/sparc/leon2/include/leon.h
+++ b/bsps/sparc/leon2/include/leon.h
@@ -80,7 +80,7 @@ extern "C" {
  *significant nibble of the trap type.
  */
 
-#define LEON_TRAP_TYPE( _source ) SPARC_ASYNCHRONOUS_TRAP((_source) + 0x10)
+#define LEON_TRAP_TYPE( _source ) SPARC_INTERRUPT_SOURCE_TO_TRAP( _source )
 
 #define LEON_TRAP_SOURCE( _trap ) SPARC_INTERRUPT_TRAP_TO_SOURCE( _trap )
 
diff --git a/bsps/sparc/leon3/include/leon.h b/bsps/sparc/leon3/include/leon.h
index 0e86dbefe1..7eed5894c6 100644
--- a/bsps/sparc/leon3/include/leon.h
+++ b/bsps/sparc/leon3/include/leon.h
@@ -42,7 +42,7 @@ extern "C" {
  *significant nibble of the trap type.
  */
 
-#define LEON_TRAP_TYPE( _source ) SPARC_ASYNCHRONOUS_TRAP((_source) + 0x10)
+#define LEON_TRAP_TYPE( _source ) SPARC_INTERRUPT_SOURCE_TO_TRAP( _source )
 
 #define LEON_TRAP_SOURCE( _trap ) SPARC_INTERRUPT_TRAP_TO_SOURCE( _trap )
 
diff --git a/cpukit/score/cpu/sparc/include/rtems/score/sparc.h 
b/cpukit/score/cpu/sparc/include/rtems/score/sparc.h
index 553ead38d8..3d9c333efa 100644
--- a/cpukit/score/cpu/sparc/include/rtems/score/sparc.h
+++ b/cpukit/score/cpu/sparc/include/rtems/score/sparc.h
@@ -225,6 +225,15 @@ extern "C" {
 #define SPARC_INTERRUPT_TRAP_TO_SOURCE( _trap ) \
   ( SPARC_REAL_TRAP_NUMBER( _trap ) - 0x10 )
 
+/**
+ * @brief Returns the asynchronous trap number associated with the specified
+ * interrupt source number.
+ *
+ * @brief _source is the interrupt source number to map.
+ */
+#define SPARC_INTERRUPT_SOURCE_TO_TRAP( _source ) \
+  ( SPARC_ASYNCHRONOUS_TRAP( _source ) + 0x10 )
+
 #ifndef ASM
 
 /**
-- 
2.26.2

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

[PATCH 1/4] sparc: Move SPARC-specific macros to sparc.h

[Sebastian Huber]

Clarify Doxygen comments.  Fix formatting.

Update #4171.
---
 .../score/cpu/sparc/include/rtems/score/cpu.h | 21 
 .../cpu/sparc/include/rtems/score/sparc.h | 32 ++-
 2 files changed, 31 insertions(+), 22 deletions(-)

diff --git a/cpukit/score/cpu/sparc/include/rtems/score/cpu.h 
b/cpukit/score/cpu/sparc/include/rtems/score/cpu.h
index e2604bb76f..8c5330b8ce 100644
--- a/cpukit/score/cpu/sparc/include/rtems/score/cpu.h
+++ b/cpukit/score/cpu/sparc/include/rtems/score/cpu.h
@@ -691,27 +691,6 @@ extern const CPU_Trap_table_entry _CPU_Trap_slot_template;
  */
 #define CPU_INTERRUPT_MAXIMUM_VECTOR_NUMBER 511
 
-/**
- * This is the bit step in a vector number to indicate it is being installed
- * as a synchronous trap.
- */
-#define SPARC_SYNCHRONOUS_TRAP_BIT_MASK 0x100
-
-/**
- * This macro indicates that @a _trap as an asynchronous trap.
- */
-#define SPARC_ASYNCHRONOUS_TRAP( _trap )(_trap)
-
-/**
- * This macro indicates that @a _trap as a synchronous trap.
- */
-#define SPARC_SYNCHRONOUS_TRAP( _trap ) ((_trap) + 256 )
-
-/**
- * This macro returns the real hardware vector number associated with @a _trap.
- */
-#define SPARC_REAL_TRAP_NUMBER( _trap ) ((_trap) % 256)
-
 /**
  * This is defined if the port has a special way to report the ISR nesting
  * level.  Most ports maintain the variable _ISR_Nest_level.
diff --git a/cpukit/score/cpu/sparc/include/rtems/score/sparc.h 
b/cpukit/score/cpu/sparc/include/rtems/score/sparc.h
index db659cc1fa..7e127f1fd5 100644
--- a/cpukit/score/cpu/sparc/include/rtems/score/sparc.h
+++ b/cpukit/score/cpu/sparc/include/rtems/score/sparc.h
@@ -167,6 +167,36 @@ extern "C" {
 #define SPARC_SWTRAP_IRQDIS_FP 11
 #endif
 
+/**
+ * @brief This is the bit step in a vector number to indicate it is being
+ *   installed as a synchronous trap.
+ */
+#define SPARC_SYNCHRONOUS_TRAP_BIT_MASK 0x100
+
+/**
+ * @brief Returns the asynchronous trap number associated with the specified
+ * the real hardware vector number.
+ *
+ * @param _trap is the real hardware vector number to map.
+ */
+#define SPARC_ASYNCHRONOUS_TRAP( _trap ) ( _trap )
+
+/**
+ * @brief Returns the synchronous trap number associated with the specified the
+ *   real hardware vector number.
+ *
+ * @param _trap is the real hardware vector number to map.
+ */
+#define SPARC_SYNCHRONOUS_TRAP( _trap ) ( ( _trap ) + 256 )
+
+/**
+ * @brief Returns the real hardware vector number associated with the specified
+ * synchronous or asynchronous trap number.
+ *
+ * @param _trap is the synchronous or asynchronous trap number to map.
+ */
+#define SPARC_REAL_TRAP_NUMBER( _trap ) ( ( _trap ) % 256 )
+
 #ifndef ASM
 
 /**
@@ -411,7 +441,7 @@ static inline uint32_t _LEON3_Get_current_processor( void )
   return asr17 >> LEON3_ASR17_PROCESSOR_INDEX_SHIFT;
 }
 
-#endif
+#endif /* ASM */
 
 #ifdef __cplusplus
 }
-- 
2.26.2

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

[PATCH 2/4] sparc: Add SPARC_IS_INTERRUPT_TRAP()

[Sebastian Huber]

Update #4171.
---
 bsps/sparc/erc32/include/erc32.h   |  4 +---
 bsps/sparc/erc32/start/setvec.c|  9 +++--
 bsps/sparc/leon2/include/leon.h|  4 +---
 bsps/sparc/leon2/start/setvec.c|  9 +++--
 bsps/sparc/leon3/include/leon.h|  4 +---
 bsps/sparc/leon3/start/setvec.c|  9 +++--
 cpukit/score/cpu/sparc/include/rtems/score/sparc.h | 14 ++
 7 files changed, 26 insertions(+), 27 deletions(-)

diff --git a/bsps/sparc/erc32/include/erc32.h b/bsps/sparc/erc32/include/erc32.h
index 7db4a6c91b..2d278fc669 100644
--- a/bsps/sparc/erc32/include/erc32.h
+++ b/bsps/sparc/erc32/include/erc32.h
@@ -87,9 +87,7 @@ extern "C" {
 
 #define ERC32_TRAP_SOURCE( _trap ) ((_trap) - 0x10)
 
-#define ERC32_Is_MEC_Trap( _trap ) \
-  ( (_trap) >= ERC32_TRAP_TYPE( ERC32_INTERRUPT_MASKED_ERRORS ) && \
-(_trap) <= ERC32_TRAP_TYPE( ERC32_INTERRUPT_WATCHDOG_TIMEOUT ) )
+#define ERC32_Is_MEC_Trap( _trap ) SPARC_IS_INTERRUPT_TRAP( _trap )
 
 /*
  *  Structure for ERC32 memory mapped registers.
diff --git a/bsps/sparc/erc32/start/setvec.c b/bsps/sparc/erc32/start/setvec.c
index 0200f422a1..73bcc99083 100644
--- a/bsps/sparc/erc32/start/setvec.c
+++ b/bsps/sparc/erc32/start/setvec.c
@@ -37,8 +37,6 @@ rtems_isr_entry set_vector(   /* returns old 
vector */
 )
 {
   rtems_isr_entry previous_isr;
-  uint32_treal_trap;
-  uint32_tsource;
 
   if ( type ) {
 rtems_interrupt_catch( handler, vector, &previous_isr );
@@ -50,11 +48,10 @@ rtems_isr_entry set_vector(   /* returns 
old vector */
 );
   }
 
-  real_trap = SPARC_REAL_TRAP_NUMBER( vector );
+  if ( SPARC_IS_INTERRUPT_TRAP( vector ) ) {
+uint32_t source;
 
-  if ( ERC32_Is_MEC_Trap( real_trap ) ) {
-
-source = ERC32_TRAP_SOURCE( real_trap );
+source = ERC32_TRAP_SOURCE( SPARC_REAL_TRAP_NUMBER( vector ) );
 
 ERC32_Clear_interrupt( source );
 ERC32_Unmask_interrupt( source );
diff --git a/bsps/sparc/leon2/include/leon.h b/bsps/sparc/leon2/include/leon.h
index 2b3379f713..49af3086ed 100644
--- a/bsps/sparc/leon2/include/leon.h
+++ b/bsps/sparc/leon2/include/leon.h
@@ -84,9 +84,7 @@ extern "C" {
 
 #define LEON_TRAP_SOURCE( _trap ) ((_trap) - 0x10)
 
-#define LEON_INT_TRAP( _trap ) \
-  ( (_trap) >= LEON_TRAP_TYPE( LEON_INTERRUPT_CORRECTABLE_MEMORY_ERROR ) && \
-(_trap) <= LEON_TRAP_TYPE( LEON_INTERRUPT_EMPTY6 ) )
+#define LEON_INT_TRAP( _trap ) SPARC_IS_INTERRUPT_TRAP( _trap )
 
 /*
  *  Structure for LEON memory mapped registers.
diff --git a/bsps/sparc/leon2/start/setvec.c b/bsps/sparc/leon2/start/setvec.c
index 3e4120611d..51647e3ee4 100644
--- a/bsps/sparc/leon2/start/setvec.c
+++ b/bsps/sparc/leon2/start/setvec.c
@@ -43,19 +43,16 @@ rtems_isr_entry set_vector(   /* returns 
old vector */
 )
 {
   rtems_isr_entry previous_isr;
-  uint32_t  real_trap;
-  uint32_t  source;
 
   if ( type )
 rtems_interrupt_catch( handler, vector, &previous_isr );
   else
 _CPU_ISR_install_raw_handler( vector, handler, (void *)&previous_isr );
 
-  real_trap = SPARC_REAL_TRAP_NUMBER( vector );
+  if ( SPARC_IS_INTERRUPT_TRAP( vector ) ) {
+uint32_t source;
 
-  if ( LEON_INT_TRAP( real_trap ) ) {
-
-source = LEON_TRAP_SOURCE( real_trap );
+source = LEON_TRAP_SOURCE( SPARC_REAL_TRAP_NUMBER( vector ) );
 
 LEON_Clear_interrupt( source );
 LEON_Unmask_interrupt( source );
diff --git a/bsps/sparc/leon3/include/leon.h b/bsps/sparc/leon3/include/leon.h
index f70fae5709..5ab0d45125 100644
--- a/bsps/sparc/leon3/include/leon.h
+++ b/bsps/sparc/leon3/include/leon.h
@@ -46,9 +46,7 @@ extern "C" {
 
 #define LEON_TRAP_SOURCE( _trap ) ((_trap) - 0x10)
 
-#define LEON_INT_TRAP( _trap ) \
-  ( (_trap) >= 0x11 && \
-(_trap) <= 0x1F )
+#define LEON_INT_TRAP( _trap ) SPARC_IS_INTERRUPT_TRAP( _trap )
 
 /* /\* */
 /*  *  This is used to manipulate the on-chip registers. */
diff --git a/bsps/sparc/leon3/start/setvec.c b/bsps/sparc/leon3/start/setvec.c
index 5b5888d51a..987e505c35 100644
--- a/bsps/sparc/leon3/start/setvec.c
+++ b/bsps/sparc/leon3/start/setvec.c
@@ -42,19 +42,16 @@ rtems_isr_entry set_vector(   /* returns 
old vector */
 )
 {
   rtems_isr_entry previous_isr;
-  uint32_t  real_trap;
-  uint32_t  source;
 
   if ( type )
 rtems_interrupt_catch( handler, vector, &previous_isr );
   else
 _CPU_ISR_install_raw_handler( vector, handler, (void *)&previous_isr );
 
-  real_trap = SPARC_REAL_TRAP_NUMBER( vector );
+  if ( SPARC_IS_INTERRUPT_TRAP( vector ) ) {
+uint32_t source;
 
-  if ( LEON_INT_TRAP( real_trap ) ) {
-
-source = LEON_TRAP_SOURCE( real_trap );
+source = LEON_TRAP_SOURCE( SPARC_REAL_TRAP_NUMBER( vector ) );
 
 LEON_Clear_interrupt( source );
 LEON_Unmask_interrupt( source );
diff --git a/cpukit/score/cpu/sparc/include/rtems/score/sparc.h 
b/cpukit/score/cpu/sparc/include/rtems/score

[PATCH 3/4] sparc: Add SPARC_INTERRUPT_TRAP_TO_SOURCE()

[Sebastian Huber]

Update #4171.
---
 bsps/sparc/erc32/include/erc32.h   |  2 +-
 bsps/sparc/erc32/start/setvec.c|  2 +-
 bsps/sparc/leon2/include/leon.h|  2 +-
 bsps/sparc/leon2/start/setvec.c|  2 +-
 bsps/sparc/leon3/include/leon.h|  2 +-
 bsps/sparc/leon3/start/setvec.c|  2 +-
 cpukit/score/cpu/sparc/include/rtems/score/sparc.h | 14 ++
 7 files changed, 20 insertions(+), 6 deletions(-)

diff --git a/bsps/sparc/erc32/include/erc32.h b/bsps/sparc/erc32/include/erc32.h
index 2d278fc669..6d79772cc7 100644
--- a/bsps/sparc/erc32/include/erc32.h
+++ b/bsps/sparc/erc32/include/erc32.h
@@ -85,7 +85,7 @@ extern "C" {
 
 #define ERC32_TRAP_TYPE( _source ) SPARC_ASYNCHRONOUS_TRAP((_source) + 0x10)
 
-#define ERC32_TRAP_SOURCE( _trap ) ((_trap) - 0x10)
+#define ERC32_TRAP_SOURCE( _trap ) SPARC_INTERRUPT_TRAP_TO_SOURCE( _trap )
 
 #define ERC32_Is_MEC_Trap( _trap ) SPARC_IS_INTERRUPT_TRAP( _trap )
 
diff --git a/bsps/sparc/erc32/start/setvec.c b/bsps/sparc/erc32/start/setvec.c
index 73bcc99083..50b6266f86 100644
--- a/bsps/sparc/erc32/start/setvec.c
+++ b/bsps/sparc/erc32/start/setvec.c
@@ -51,7 +51,7 @@ rtems_isr_entry set_vector(   /* returns old 
vector */
   if ( SPARC_IS_INTERRUPT_TRAP( vector ) ) {
 uint32_t source;
 
-source = ERC32_TRAP_SOURCE( SPARC_REAL_TRAP_NUMBER( vector ) );
+source = SPARC_INTERRUPT_TRAP_TO_SOURCE( vector );
 
 ERC32_Clear_interrupt( source );
 ERC32_Unmask_interrupt( source );
diff --git a/bsps/sparc/leon2/include/leon.h b/bsps/sparc/leon2/include/leon.h
index 49af3086ed..1d58aa7d39 100644
--- a/bsps/sparc/leon2/include/leon.h
+++ b/bsps/sparc/leon2/include/leon.h
@@ -82,7 +82,7 @@ extern "C" {
 
 #define LEON_TRAP_TYPE( _source ) SPARC_ASYNCHRONOUS_TRAP((_source) + 0x10)
 
-#define LEON_TRAP_SOURCE( _trap ) ((_trap) - 0x10)
+#define LEON_TRAP_SOURCE( _trap ) SPARC_INTERRUPT_TRAP_TO_SOURCE( _trap )
 
 #define LEON_INT_TRAP( _trap ) SPARC_IS_INTERRUPT_TRAP( _trap )
 
diff --git a/bsps/sparc/leon2/start/setvec.c b/bsps/sparc/leon2/start/setvec.c
index 51647e3ee4..1557c77942 100644
--- a/bsps/sparc/leon2/start/setvec.c
+++ b/bsps/sparc/leon2/start/setvec.c
@@ -52,7 +52,7 @@ rtems_isr_entry set_vector(   /* returns old 
vector */
   if ( SPARC_IS_INTERRUPT_TRAP( vector ) ) {
 uint32_t source;
 
-source = LEON_TRAP_SOURCE( SPARC_REAL_TRAP_NUMBER( vector ) );
+source = SPARC_INTERRUPT_TRAP_TO_SOURCE( vector );
 
 LEON_Clear_interrupt( source );
 LEON_Unmask_interrupt( source );
diff --git a/bsps/sparc/leon3/include/leon.h b/bsps/sparc/leon3/include/leon.h
index 5ab0d45125..0e86dbefe1 100644
--- a/bsps/sparc/leon3/include/leon.h
+++ b/bsps/sparc/leon3/include/leon.h
@@ -44,7 +44,7 @@ extern "C" {
 
 #define LEON_TRAP_TYPE( _source ) SPARC_ASYNCHRONOUS_TRAP((_source) + 0x10)
 
-#define LEON_TRAP_SOURCE( _trap ) ((_trap) - 0x10)
+#define LEON_TRAP_SOURCE( _trap ) SPARC_INTERRUPT_TRAP_TO_SOURCE( _trap )
 
 #define LEON_INT_TRAP( _trap ) SPARC_IS_INTERRUPT_TRAP( _trap )
 
diff --git a/bsps/sparc/leon3/start/setvec.c b/bsps/sparc/leon3/start/setvec.c
index 987e505c35..f9bccd490a 100644
--- a/bsps/sparc/leon3/start/setvec.c
+++ b/bsps/sparc/leon3/start/setvec.c
@@ -51,7 +51,7 @@ rtems_isr_entry set_vector(   /* returns old 
vector */
   if ( SPARC_IS_INTERRUPT_TRAP( vector ) ) {
 uint32_t source;
 
-source = LEON_TRAP_SOURCE( SPARC_REAL_TRAP_NUMBER( vector ) );
+source = SPARC_INTERRUPT_TRAP_TO_SOURCE( vector );
 
 LEON_Clear_interrupt( source );
 LEON_Unmask_interrupt( source );
diff --git a/cpukit/score/cpu/sparc/include/rtems/score/sparc.h 
b/cpukit/score/cpu/sparc/include/rtems/score/sparc.h
index c2b6aeea6b..553ead38d8 100644
--- a/cpukit/score/cpu/sparc/include/rtems/score/sparc.h
+++ b/cpukit/score/cpu/sparc/include/rtems/score/sparc.h
@@ -211,6 +211,20 @@ extern "C" {
   ( SPARC_REAL_TRAP_NUMBER( _trap ) >= 0x11 \
 && SPARC_REAL_TRAP_NUMBER( _trap) <= 0x1f )
 
+/**
+ * @brief Returns the interrupt source number associated with the specified
+ *   interrupt trap number.
+ *
+ * Interrupt trap numbers are real hardware vector numbers, synchronous trap
+ * numbers, and asynchronous trap numbers for which SPARC_IS_INTERRUPT_TRAP()
+ * returns true.
+ *
+ * @brief _trap is the real hardware vector number, synchronous trap number, or
+ *   asynchronous trap number to map.
+ */
+#define SPARC_INTERRUPT_TRAP_TO_SOURCE( _trap ) \
+  ( SPARC_REAL_TRAP_NUMBER( _trap ) - 0x10 )
+
 #ifndef ASM
 
 /**
-- 
2.26.2

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

[PATCH 0/4] Reduce copy and paste in the SPARC port

[Sebastian Huber]

This patch set just removes a bit of copy and paste in the SPARC port.

Sebastian Huber (4):
  sparc: Move SPARC-specific macros to sparc.h
  sparc: Add SPARC_IS_INTERRUPT_TRAP()
  sparc: Add SPARC_INTERRUPT_TRAP_TO_SOURCE()
  sparc: Add SPARC_INTERRUPT_SOURCE_TO_TRAP()

 bsps/sparc/erc32/include/erc32.h  |  8 +--
 bsps/sparc/erc32/start/setvec.c   |  9 +--
 bsps/sparc/leon2/include/leon.h   |  8 +--
 bsps/sparc/leon2/start/setvec.c   |  9 +--
 bsps/sparc/leon3/include/leon.h   |  8 +--
 bsps/sparc/leon3/start/setvec.c   |  9 +--
 .../score/cpu/sparc/include/rtems/score/cpu.h | 21 --
 .../cpu/sparc/include/rtems/score/sparc.h | 69 ++-
 8 files changed, 86 insertions(+), 55 deletions(-)

-- 
2.26.2

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

Re: [PATCH 2/4] sparc: Add SPARC_IS_INTERRUPT_TRAP()

[Sebastian Huber]

On 05/11/2020 16:09, Sebastian Huber wrote:


+ * @brief _trap is the real hardware vector number, synchronous trap number, or
+ *   asynchronous trap number to check.

I  already fixed the @brief -> @param typos.

--
embedded brains GmbH
Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
Phone: +49-89-18 94 741 - 16
Fax:   +49-89-18 94 741 - 08
PGP: Public key available on request.

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

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

Re: [PATCH v3 0/2] Add networking support for griscv bsp

[Jiri Gaisler]

Does anyone object to this patch? Otherwise I will go ahead and commit it...

Jiri.

On 11/1/20 4:46 PM, Jiri Gaisler wrote:
> Third attempt. Needed to fix the waf build and add correct link address
> for the griscv bsp. Tested with rtems-netdemos.
>
> Jiri Gaisler (2):
>   Add networking support for griscv bsp
>   Add correct link address for griscv waf build
>
>  bsps/riscv/griscv/console/console.c  |  2 +-
>  bsps/riscv/griscv/include/bsp.h  | 14 +
>  bsps/riscv/griscv/net/griscv_greth.c | 59 
>  bsps/shared/grlib/net/greth.c| 24 
>  bsps/shared/net/greth2.c |  6 +-
>  c/src/lib/libbsp/riscv/griscv/Makefile.am|  6 ++
>  spec/build/bsps/riscv/griscv/grp.yml |  2 +
>  spec/build/bsps/riscv/griscv/objnetnosmp.yml | 18 ++
>  spec/build/bsps/riscv/optrambegin.yml|  3 +
>  spec/build/bsps/riscv/optramsize.yml |  3 +
>  10 files changed, 123 insertions(+), 14 deletions(-)
>  create mode 100644 bsps/riscv/griscv/net/griscv_greth.c
>  create mode 100644 spec/build/bsps/riscv/griscv/objnetnosmp.yml
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

80 or 79 characters limit?

[Sebastian Huber]

Hello,

I review currently the Coding Conventions. Should the 80 characters 
limit be really a 79 characters limit with the \n as the invisible 80th 
character?


--
embedded brains GmbH
Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
Phone: +49-89-18 94 741 - 16
Fax:   +49-89-18 94 741 - 08
PGP: Public key available on request.

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

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

Re: Blockers for Cutover to Waf

[Joel Sherrill]

On Thu, Nov 5, 2020 at 9:05 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> Hello Joel,
>
> On 28/10/2020 15:25, Joel Sherrill wrote:
> > Hi
> >
> > I didn't want to hijack the greth thread with this but there are open
> > wafblocker issues which prevent the cutover to waf.
> >
> >
> https://devel.rtems.org/query?status=accepted&status=assigned&status=new&status=reopened&keywords=~wafblocker&group=status&col=id&col=summary&col=owner&col=type&col=priority&col=component&col=version&order=priority
> > <
> https://devel.rtems.org/query?status=accepted&status=assigned&status=new&status=reopened&keywords=~wafblocker&group=status&col=id&col=summary&col=owner&col=type&col=priority&col=component&col=version&order=priority
> >
> >
> > These need to be addressed.
>
> the only blocking issue from my point of view is
>
> https://devel.rtems.org/ticket/4124
>
> for which I provided a patch
>

https://devel.rtems.org/ticket/4123 and  https://devel.rtems.org/ticket/4145

need to be addressed or automated tests will fail.

I will acquiesce on the other documentation type issues.

>
> https://lists.rtems.org/pipermail/devel/2020-November/063024.html
>
> All other issues can be addressed after the removal of the old build
> system. Maintaining the old build system needs extra time which cannot
> be used to address these issues for example.
>
> --
> embedded brains GmbH
> Sebastian HUBER
> Dornierstr. 4
> 82178 Puchheim
> Germany
> email: sebastian.hu...@embedded-brains.de
> Phone: +49-89-18 94 741 - 16
> Fax:   +49-89-18 94 741 - 08
> PGP: Public key available on request.
>
> embedded brains GmbH
> Registergericht: Amtsgericht München
> Registernummer: HRB 157899
> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
> Unsere Datenschutzerklärung finden Sie hier:
> https://embedded-brains.de/datenschutzerklaerung/
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Blockers for Cutover to Waf

[Sebastian Huber]

On 05/11/2020 16:35, Joel Sherrill wrote:



On Thu, Nov 5, 2020 at 9:05 AM Sebastian Huber 
> wrote:


Hello Joel,

On 28/10/2020 15:25, Joel Sherrill wrote:
> Hi
>
> I didn't want to hijack the greth thread with this but there are
open
> wafblocker issues which prevent the cutover to waf.
>
>

https://devel.rtems.org/query?status=accepted&status=assigned&status=new&status=reopened&keywords=~wafblocker&group=status&col=id&col=summary&col=owner&col=type&col=priority&col=component&col=version&order=priority



>

>
>
> These need to be addressed.

the only blocking issue from my point of view is

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


for which I provided a patch


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


Sorry I confused the numbers. I have a patch for this one:

https://lists.rtems.org/pipermail/devel/2020-November/063024.html 



and https://devel.rtems.org/ticket/4145 


need to be addressed or automated tests will fail.
This only needs to be updated if someone updates the RTEMS commit in the 
build set or does it pick up the latest RTEMS?


--
embedded brains GmbH
Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
Phone: +49-89-18 94 741 - 16
Fax:   +49-89-18 94 741 - 08
PGP: Public key available on request.

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

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

Re: 80 or 79 characters limit?

[Joel Sherrill]

On Thu, Nov 5, 2020, 9:26 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> Hello,
>
> I review currently the Coding Conventions. Should the 80 characters
> limit be really a 79 characters limit with the \n as the invisible 80th
> character?
>

Yes.

As old as this makes me feel, I remember printers which did an automatic
linefeed and then the newline one if you hit column 80. So it really is 79
unfortunately.

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

Re: Blockers for Cutover to Waf

[Joel Sherrill]

On Thu, Nov 5, 2020, 9:39 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

>
> On 05/11/2020 16:35, Joel Sherrill wrote:
> >
> >
> > On Thu, Nov 5, 2020 at 9:05 AM Sebastian Huber
> >  > > wrote:
> >
> > Hello Joel,
> >
> > On 28/10/2020 15:25, Joel Sherrill wrote:
> > > Hi
> > >
> > > I didn't want to hijack the greth thread with this but there are
> > open
> > > wafblocker issues which prevent the cutover to waf.
> > >
> > >
> >
> https://devel.rtems.org/query?status=accepted&status=assigned&status=new&status=reopened&keywords=~wafblocker&group=status&col=id&col=summary&col=owner&col=type&col=priority&col=component&col=version&order=priority
> > <
> https://devel.rtems.org/query?status=accepted&status=assigned&status=new&status=reopened&keywords=~wafblocker&group=status&col=id&col=summary&col=owner&col=type&col=priority&col=component&col=version&order=priority
> >
> >
> > >
> > <
> https://devel.rtems.org/query?status=accepted&status=assigned&status=new&status=reopened&keywords=~wafblocker&group=status&col=id&col=summary&col=owner&col=type&col=priority&col=component&col=version&order=priority
> > <
> https://devel.rtems.org/query?status=accepted&status=assigned&status=new&status=reopened&keywords=~wafblocker&group=status&col=id&col=summary&col=owner&col=type&col=priority&col=component&col=version&order=priority
> >>
> > >
> > > These need to be addressed.
> >
> > the only blocking issue from my point of view is
> >
> > https://devel.rtems.org/ticket/4124
> > 
> >
> > for which I provided a patch
> >
> >
> > https://devel.rtems.org/ticket/4123  >
>
> Sorry I confused the numbers. I have a patch for this one:
>
> https://lists.rtems.org/pipermail/devel/2020-November/063024.html
> 
>
> > and https://devel.rtems.org/ticket/4145
> > 
> > need to be addressed or automated tests will fail.
> This only needs to be updated if someone updates the RTEMS commit in the
> build set or does it pick up the latest RTEMS?
>

That's probably ok for the RSB kernel packages but at least Chris should
speak up.

For rtems-bsps at the top of the tree, that has to be fixed

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

Re: Blockers for Cutover to Waf

[Sebastian Huber]

On 05/11/2020 16:46, Joel Sherrill wrote:


For rtems-bsps at the top of the tree, that has to be fixed
https://lists.rtems.org/pipermail/devel/2020-November/063024.html 



--
embedded brains GmbH
Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
Phone: +49-89-18 94 741 - 16
Fax:   +49-89-18 94 741 - 08
PGP: Public key available on request.

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

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

[PATCH] build: Place cache file in build directory

[Sebastian Huber]

This improves support for the --out option.
---
 wscript | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/wscript b/wscript
index 57ec6ff7f7..5f6958dbf3 100755
--- a/wscript
+++ b/wscript
@@ -1135,8 +1135,8 @@ def load_from_yaml(load, ctx, data_by_uid, base, path):
 
 
 def load_items_in_directory(ctx, ctors, path):
-f = ctx.path.make_node(
-"build/c4che/" + re.sub(r"[^\w]", "_", path) + ".pickle"
+f = ctx.bldnode.make_node(
+"c4che/" + re.sub(r"[^\w]", "_", path) + ".pickle"
 )
 f.parent.mkdir()
 cache_file = f.abspath()
-- 
2.26.2

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

Out of tree builds with waf?

[Sebastian Huber]

Hello,

I tried to do an out of tree build with waf:

~/src/rtems/waf configure --rtems-config $PWD/config.ini --out 
$PWD/build --top $HOME/src/rtems


This seems to work, however, I get a message like this (CWD /home ...):

~/src/rtems/waf --out $PWD/build --top $HOME/src/rtems
Waf: Entering directory 
`/home/EB/sebastian_h/src/rtems-source-builder/tmp/build'
Waf: Leaving directory 
`/home/EB/sebastian_h/src/rtems-source-builder/tmp/build'

'build' finished successfully (0.332s)
Waf: Entering directory 
`/home/EB/sebastian_h/src/rtems-source-builder/tmp/build/sparc/erc32'
CWD /home/EB/sebastian_h/src/rtems-source-builder/tmp is not under 
/home/EB/sebastian_h/src/rtems, forcing --targets=* (run distclean?)
Waf: Leaving directory 
`/home/EB/sebastian_h/src/rtems-source-builder/tmp/build/sparc/erc32'

'build_sparc/erc32' finished successfully (0.438s)

I this something to worry about? Are out of tree builds supported by waf?

--
embedded brains GmbH
Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
Phone: +49-89-18 94 741 - 16
Fax:   +49-89-18 94 741 - 08
PGP: Public key available on request.

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

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

Re: Out of tree builds with waf?

[Joel Sherrill]

On Thu, Nov 5, 2020 at 10:04 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> Hello,
>
> I tried to do an out of tree build with waf:
>
> ~/src/rtems/waf configure --rtems-config $PWD/config.ini --out
> $PWD/build --top $HOME/src/rtems
>
> This seems to work, however, I get a message like this (CWD /home ...):
>
> ~/src/rtems/waf --out $PWD/build --top $HOME/src/rtems
> Waf: Entering directory
> `/home/EB/sebastian_h/src/rtems-source-builder/tmp/build'
> Waf: Leaving directory
> `/home/EB/sebastian_h/src/rtems-source-builder/tmp/build'
> 'build' finished successfully (0.332s)
> Waf: Entering directory
> `/home/EB/sebastian_h/src/rtems-source-builder/tmp/build/sparc/erc32'
> CWD /home/EB/sebastian_h/src/rtems-source-builder/tmp is not under
> /home/EB/sebastian_h/src/rtems, forcing --targets=* (run distclean?)
> Waf: Leaving directory
> `/home/EB/sebastian_h/src/rtems-source-builder/tmp/build/sparc/erc32'
> 'build_sparc/erc32' finished successfully (0.438s)
>
> I this something to worry about? Are out of tree builds supported by waf?
>

I hope they can be. Or at least the build directory name changed based
on user input.

For automated testing, I have been building multiple BSPs in parallel
completely independently. I don't know a way to do this with waf.

--joel

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

Re: [PATCH v4 0/1] Test for clock_nanosleep() with CLOCK_MONOTONIC option

[Utkarsh Rai]

On Thu, Nov 5, 2020 at 12:13 AM Gedare Bloom  wrote:

> i need to find time to look at this, and try it out.
>
> Does this compile? e.g., I don't see a definition of OPERATION_COUNT
>

Yes,  the OPERATION_COUNT is defined in "timesys.h".

>
> On Wed, Oct 28, 2020 at 7:34 AM Utkarsh Rai 
> wrote:
> >
> > Ping.
> >
> > On Wed, Oct 21, 2020 at 8:58 AM Utkarsh Rai 
> wrote:
> >>
> >> This patch has the tests for clock_nanosleep with the CLOCK_MONOTONIC
> option.
> >> The psxtests/psxclocknanosleep01/.. tests for valid timeout values as
> well as
> >> for the effect on timeout delay when REALTIME clock is modified(no
> effect).
> >> The timing tests are the similar to that for the REALTIME
> option(yielding and
> >> blocking).
> >>
> >> Utkarsh Rai (1):
> >>   Test for clock_nanosleep() with CLOCK_MONOTONIC option
> >>
> >>  .../psxtests/psxclocknanosleep01.yml  |  19 +++
> >>  spec/build/testsuites/psxtmtests/grp.yml  |   4 +
> >>  .../psxtmtests/psxtmclocknanosleep04.yml  |  19 +++
> >>  .../psxtmtests/psxtmclocknanosleep05.yml  |  19 +++
> >>  .../psxtests/psxclocknanosleep01/init.c   | 145 ++
> >>  .../psxclocknanosleep01.doc   |  13 ++
> >>  .../psxclocknanosleep01.scn   |  50 ++
> >>  .../psxtmtests/psxtmclocknanosleep04/init.c   |  70 +
> >>  .../psxtmtests/psxtmclocknanosleep05/init.c   | 116 ++
> >>  9 files changed, 455 insertions(+)
> >>  create mode 100644
> spec/build/testsuites/psxtests/psxclocknanosleep01.yml
> >>  create mode 100644
> spec/build/testsuites/psxtmtests/psxtmclocknanosleep04.yml
> >>  create mode 100644
> spec/build/testsuites/psxtmtests/psxtmclocknanosleep05.yml
> >>  create mode 100644 testsuites/psxtests/psxclocknanosleep01/init.c
> >>  create mode 100644
> testsuites/psxtests/psxclocknanosleep01/psxclocknanosleep01.doc
> >>  create mode 100644
> testsuites/psxtests/psxclocknanosleep01/psxclocknanosleep01.scn
> >>  create mode 100644 testsuites/psxtmtests/psxtmclocknanosleep04/init.c
> >>  create mode 100644 testsuites/psxtmtests/psxtmclocknanosleep05/init.c
> >>
> >> --
> >> 2.25.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: Out of tree builds with waf?

[Sebastian Huber]

On 05/11/2020 17:09, Joel Sherrill wrote:




On Thu, Nov 5, 2020 at 10:04 AM Sebastian Huber 
> wrote:


Hello,

I tried to do an out of tree build with waf:

~/src/rtems/waf configure --rtems-config $PWD/config.ini --out
$PWD/build --top $HOME/src/rtems

This seems to work, however, I get a message like this (CWD /home
...):

~/src/rtems/waf --out $PWD/build --top $HOME/src/rtems
Waf: Entering directory
`/home/EB/sebastian_h/src/rtems-source-builder/tmp/build'
Waf: Leaving directory
`/home/EB/sebastian_h/src/rtems-source-builder/tmp/build'
'build' finished successfully (0.332s)
Waf: Entering directory
`/home/EB/sebastian_h/src/rtems-source-builder/tmp/build/sparc/erc32'
CWD /home/EB/sebastian_h/src/rtems-source-builder/tmp is not under
/home/EB/sebastian_h/src/rtems, forcing --targets=* (run distclean?)
Waf: Leaving directory
`/home/EB/sebastian_h/src/rtems-source-builder/tmp/build/sparc/erc32'
'build_sparc/erc32' finished successfully (0.438s)

I this something to worry about? Are out of tree builds supported
by waf?


I hope they can be. Or at least the build directory name changed based
on user input.

For automated testing, I have been building multiple BSPs in parallel
completely independently. I don't know a way to do this with waf.


If out of tree builds and a read-only source tree should be supported by 
the build system, then this should be added to the goals in 
eng/build-system.rst.


I need some support from a waf expert to add proper support for this to 
the wscript.


Another open issue is the --target option which currently doesn't work.

--
embedded brains GmbH
Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
Phone: +49-89-18 94 741 - 16
Fax:   +49-89-18 94 741 - 08
PGP: Public key available on request.

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

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

Re: [PATCH] build: Place cache file in build directory

[Gedare Bloom]

ok I think. the commit message confused me since the c4che was in the
'build/' directory already, now you move to the directory in which the
build happens.

I guess this means if one builds in the source tree and doesn't
specify --out, they will get c4che in rtems.git source? This directory
should be added to gitignore then

On Thu, Nov 5, 2020 at 9:00 AM Sebastian Huber
 wrote:
>
> This improves support for the --out option.
> ---
>  wscript | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/wscript b/wscript
> index 57ec6ff7f7..5f6958dbf3 100755
> --- a/wscript
> +++ b/wscript
> @@ -1135,8 +1135,8 @@ def load_from_yaml(load, ctx, data_by_uid, base, path):
>
>
>  def load_items_in_directory(ctx, ctors, path):
> -f = ctx.path.make_node(
> -"build/c4che/" + re.sub(r"[^\w]", "_", path) + ".pickle"
> +f = ctx.bldnode.make_node(
> +"c4che/" + re.sub(r"[^\w]", "_", path) + ".pickle"
>  )
>  f.parent.mkdir()
>  cache_file = f.abspath()
> --
> 2.26.2
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 1/4] sparc: Move SPARC-specific macros to sparc.h

[Gedare Bloom]

On Thu, Nov 5, 2020 at 8:09 AM Sebastian Huber
 wrote:
>
> Clarify Doxygen comments.  Fix formatting.
>
> Update #4171.
> ---
>  .../score/cpu/sparc/include/rtems/score/cpu.h | 21 
>  .../cpu/sparc/include/rtems/score/sparc.h | 32 ++-
>  2 files changed, 31 insertions(+), 22 deletions(-)
>
> diff --git a/cpukit/score/cpu/sparc/include/rtems/score/cpu.h 
> b/cpukit/score/cpu/sparc/include/rtems/score/cpu.h
> index e2604bb76f..8c5330b8ce 100644
> --- a/cpukit/score/cpu/sparc/include/rtems/score/cpu.h
> +++ b/cpukit/score/cpu/sparc/include/rtems/score/cpu.h
> @@ -691,27 +691,6 @@ extern const CPU_Trap_table_entry 
> _CPU_Trap_slot_template;
>   */
>  #define CPU_INTERRUPT_MAXIMUM_VECTOR_NUMBER 511
>
> -/**
> - * This is the bit step in a vector number to indicate it is being installed
> - * as a synchronous trap.
> - */
> -#define SPARC_SYNCHRONOUS_TRAP_BIT_MASK 0x100
> -
> -/**
> - * This macro indicates that @a _trap as an asynchronous trap.
> - */
> -#define SPARC_ASYNCHRONOUS_TRAP( _trap )(_trap)
> -
> -/**
> - * This macro indicates that @a _trap as a synchronous trap.
> - */
> -#define SPARC_SYNCHRONOUS_TRAP( _trap ) ((_trap) + 256 )
> -
> -/**
> - * This macro returns the real hardware vector number associated with @a 
> _trap.
> - */
> -#define SPARC_REAL_TRAP_NUMBER( _trap ) ((_trap) % 256)
> -
>  /**
>   * This is defined if the port has a special way to report the ISR nesting
>   * level.  Most ports maintain the variable _ISR_Nest_level.
> diff --git a/cpukit/score/cpu/sparc/include/rtems/score/sparc.h 
> b/cpukit/score/cpu/sparc/include/rtems/score/sparc.h
> index db659cc1fa..7e127f1fd5 100644
> --- a/cpukit/score/cpu/sparc/include/rtems/score/sparc.h
> +++ b/cpukit/score/cpu/sparc/include/rtems/score/sparc.h
> @@ -167,6 +167,36 @@ extern "C" {
>  #define SPARC_SWTRAP_IRQDIS_FP 11
>  #endif
>
> +/**
> + * @brief This is the bit step in a vector number to indicate it is being
> + *   installed as a synchronous trap.
> + */
> +#define SPARC_SYNCHRONOUS_TRAP_BIT_MASK 0x100
> +
> +/**
> + * @brief Returns the asynchronous trap number associated with the specified
> + * the real hardware vector number.
> + *
> + * @param _trap is the real hardware vector number to map.
> + */
> +#define SPARC_ASYNCHRONOUS_TRAP( _trap ) ( _trap )
> +
> +/**
> + * @brief Returns the synchronous trap number associated with the specified 
> the
delete trailing 'the'

> + *   real hardware vector number.
> + *
> + * @param _trap is the real hardware vector number to map.
> + */
> +#define SPARC_SYNCHRONOUS_TRAP( _trap ) ( ( _trap ) + 256 )
> +
> +/**
> + * @brief Returns the real hardware vector number associated with the 
> specified
> + * synchronous or asynchronous trap number.
> + *
> + * @param _trap is the synchronous or asynchronous trap number to map.
> + */
> +#define SPARC_REAL_TRAP_NUMBER( _trap ) ( ( _trap ) % 256 )
> +
>  #ifndef ASM
>
>  /**
> @@ -411,7 +441,7 @@ static inline uint32_t _LEON3_Get_current_processor( void 
> )
>return asr17 >> LEON3_ASR17_PROCESSOR_INDEX_SHIFT;
>  }
>
> -#endif
> +#endif /* ASM */
>
>  #ifdef __cplusplus
>  }
> --
> 2.26.2
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] build: Place cache file in build directory

[Sebastian Huber]

On 05/11/2020 18:00, Gedare Bloom wrote:


ok I think. the commit message confused me since the c4che was in the
'build/' directory already, now you move to the directory in which the
build happens.

I guess this means if one builds in the source tree and doesn't
specify --out, they will get c4che in rtems.git source? This directory
should be added to gitignore then
Previously, the cache file was placed in the source directory under 
"build/...". Now, it is placed in the build directory, which is "build" 
by default. So, if you don't use the --out option nothing changes.


--
embedded brains GmbH
Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
Phone: +49-89-18 94 741 - 16
Fax:   +49-89-18 94 741 - 08
PGP: Public key available on request.

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

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

Re: [PATCH] build: Place cache file in build directory

[Gedare Bloom]

On Thu, Nov 5, 2020 at 10:13 AM Sebastian Huber
 wrote:
>
> On 05/11/2020 18:00, Gedare Bloom wrote:
>
> > ok I think. the commit message confused me since the c4che was in the
> > 'build/' directory already, now you move to the directory in which the
> > build happens.
> >
> > I guess this means if one builds in the source tree and doesn't
> > specify --out, they will get c4che in rtems.git source? This directory
> > should be added to gitignore then
> Previously, the cache file was placed in the source directory under
> "build/...". Now, it is placed in the build directory, which is "build"
> by default. So, if you don't use the --out option nothing changes.
>
Aha! Ok then, thanks

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

Re: Out of tree builds with waf?

[Andrew Butterfield]

Hi Sebastian,

 I'm not a waf expert, but might this section in their book help?

https://waf.io/book/#_fundamental_waf_commands 


Can variables `top` and `out` in the example there be manipulated to do want 
you want?

Regards, Andrew


> On 5 Nov 2020, at 16:45, Sebastian Huber  
> wrote:
> 
> On 05/11/2020 17:09, Joel Sherrill wrote:
> 
>> 
>> 
>> On Thu, Nov 5, 2020 at 10:04 AM Sebastian Huber 
>> > > wrote:
>> 
>>Hello,
>> 
>>I tried to do an out of tree build with waf:
>> 
>>~/src/rtems/waf configure --rtems-config $PWD/config.ini --out
>>$PWD/build --top $HOME/src/rtems
>> 
>>This seems to work, however, I get a message like this (CWD /home
>>...):
>> 
>>~/src/rtems/waf --out $PWD/build --top $HOME/src/rtems
>>Waf: Entering directory
>>`/home/EB/sebastian_h/src/rtems-source-builder/tmp/build'
>>Waf: Leaving directory
>>`/home/EB/sebastian_h/src/rtems-source-builder/tmp/build'
>>'build' finished successfully (0.332s)
>>Waf: Entering directory
>>`/home/EB/sebastian_h/src/rtems-source-builder/tmp/build/sparc/erc32'
>>CWD /home/EB/sebastian_h/src/rtems-source-builder/tmp is not under
>>/home/EB/sebastian_h/src/rtems, forcing --targets=* (run distclean?)
>>Waf: Leaving directory
>>`/home/EB/sebastian_h/src/rtems-source-builder/tmp/build/sparc/erc32'
>>'build_sparc/erc32' finished successfully (0.438s)
>> 
>>I this something to worry about? Are out of tree builds supported
>>by waf?
>> 
>> 
>> I hope they can be. Or at least the build directory name changed based
>> on user input.
>> 
>> For automated testing, I have been building multiple BSPs in parallel
>> completely independently. I don't know a way to do this with waf.
> 
> If out of tree builds and a read-only source tree should be supported by the 
> build system, then this should be added to the goals in eng/build-system.rst.
> 
> I need some support from a waf expert to add proper support for this to the 
> wscript.
> 
> Another open issue is the --target option which currently doesn't work.
> 
> -- 
> embedded brains GmbH
> Sebastian HUBER
> Dornierstr. 4
> 82178 Puchheim
> Germany
> email: sebastian.hu...@embedded-brains.de
> Phone: +49-89-18 94 741 - 16
> Fax:   +49-89-18 94 741 - 08
> PGP: Public key available on request.
> 
> embedded brains GmbH
> Registergericht: Amtsgericht München
> Registernummer: HRB 157899
> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
> Unsere Datenschutzerklärung finden Sie hier: 
> https://embedded-brains.de/datenschutzerklaerung/
> 
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel


Andrew Butterfield Tel: +353-1-896-2517 Fax: +353-1-677-2204
Lero@TCD, Head of Software Foundations & Verification Research Group
School of Computer Science and Statistics,
Room G.39, O'Reilly Institute, Trinity College, University of Dublin
 http://www.scss.tcd.ie/Andrew.Butterfield/


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

Re: Out of tree builds with waf?

[Sebastian Huber]

On 05/11/2020 18:16, Andrew Butterfield wrote:


 I'm not a waf expert, but might this section in their book help?

https://waf.io/book/#_fundamental_waf_commands 



Can variables `top` and `out` in the example there be manipulated to 
do want you want?


Yes, the --top and --out options works somehow, but I get a warning like 
this:


Waf: Entering directory 
`/home/EB/sebastian_h/src/rtems-source-builder/tmp/build/sparc/erc32'
CWD /home/EB/sebastian_h/src/rtems-source-builder/tmp is not under 
/home/EB/sebastian_h/src/rtems, forcing --targets=* (run distclean?)


Also the documentation says "Though Waf may be called from any folder 
containing a /wscript/ file,", so I am not sure if this is really 
supported what I am doing.


--
embedded brains GmbH
Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
Phone: +49-89-18 94 741 - 16
Fax:   +49-89-18 94 741 - 08
PGP: Public key available on request.

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

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

Re: Out of tree builds with waf?

[Sebastian Huber]

On 05/11/2020 18:22, Sebastian Huber wrote:

On 05/11/2020 18:16, Andrew Butterfield wrote:


 I'm not a waf expert, but might this section in their book help?

https://waf.io/book/#_fundamental_waf_commands 



Can variables `top` and `out` in the example there be manipulated to 
do want you want?


Yes, the --top and --out options works somehow, but I get a warning 
like this:


Waf: Entering directory 
`/home/EB/sebastian_h/src/rtems-source-builder/tmp/build/sparc/erc32'
CWD /home/EB/sebastian_h/src/rtems-source-builder/tmp is not under 
/home/EB/sebastian_h/src/rtems, forcing --targets=* (run distclean?)


Also the documentation says "Though Waf may be called from any folder 
containing a /wscript/ file,", so I am not sure if this is really 
supported what I am doing.


What works is something like this:

./waf configure --out $PWD/tmp/xxx/build

called from the source tree. However, this has some side-effects.

1. A .waf* directory is created in the source tree (this is an issue 
with a read-only source tree).


2. Waf somehow remembers this configuration. You can call "./waf" to 
build it. So, there must be some hidden state in the source tree. This 
is not really an out of tree build. You cannot have multiple independent 
build trees.


--
embedded brains GmbH
Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
Phone: +49-89-18 94 741 - 16
Fax:   +49-89-18 94 741 - 08
PGP: Public key available on request.

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

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

Re: Out of tree builds with waf?

[Karel Gardas]

On 11/5/20 6:27 PM, Sebastian Huber wrote:
> 2. Waf somehow remembers this configuration. You can call "./waf" to
> build it. So, there must be some hidden state in the source tree. This
> is not really an out of tree build. You cannot have multiple independent
> build trees.

When your build system sucks and does not support out-of-tree builds,
then always last hope is to link dir. e.g. install lndir (from
xutils-dev on ubuntu 20.04, your distro may have it somewhere else) and
then just lndir  -- which will create directory
structure and to it symbolic links of all files as in source dir.

This way, even stubborn build systems may be taught to support out of
source tree builds...

Karel


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

Re: Blockers for Cutover to Waf

[Joel Sherrill]

On Thu, Nov 5, 2020 at 9:47 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> On 05/11/2020 16:46, Joel Sherrill wrote:
>
> > For rtems-bsps at the top of the tree, that has to be fixed
> https://lists.rtems.org/pipermail/devel/2020-November/063024.html
> 
>

I guess feel free to commit and close these issues.

Then we can make a test sweep and cut over if all agree.

--joel

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

Re: Out of tree builds with waf?

[Sebastian Huber]

On 05/11/2020 18:27, Sebastian Huber wrote:



On 05/11/2020 18:22, Sebastian Huber wrote:

On 05/11/2020 18:16, Andrew Butterfield wrote:


 I'm not a waf expert, but might this section in their book help?

https://waf.io/book/#_fundamental_waf_commands 



Can variables `top` and `out` in the example there be manipulated to 
do want you want?


Yes, the --top and --out options works somehow, but I get a warning 
like this:


Waf: Entering directory 
`/home/EB/sebastian_h/src/rtems-source-builder/tmp/build/sparc/erc32'
CWD /home/EB/sebastian_h/src/rtems-source-builder/tmp is not under 
/home/EB/sebastian_h/src/rtems, forcing --targets=* (run distclean?)


Also the documentation says "Though Waf may be called from any folder 
containing a /wscript/ file,", so I am not sure if this is really 
supported what I am doing.


What works is something like this:

./waf configure --out $PWD/tmp/xxx/build

called from the source tree. However, this has some side-effects.

1. A .waf* directory is created in the source tree (this is an issue 
with a read-only source tree).


2. Waf somehow remembers this configuration. You can call "./waf" to 
build it. So, there must be some hidden state in the source tree. This 
is not really an out of tree build. You cannot have multiple 
independent build trees.


This happens if I use a read-only source tree:

~/tmp/out-of-tree > pwd
/home/EB/sebastian_h/tmp/out-of-tree
~/tmp/out-of-tree > ~/src/rtems/waf --top $HOME/src/rtems-read-only 
--out $PWD/build configure --rtems-config $PWD/config.ini
Setting top to   : 
/home/EB/sebastian_h/src/rtems-read-only
Setting out to   : 
/home/EB/sebastian_h/tmp/out-of-tree/build

Configure board support package (BSP)    : sparc/erc32
Checking for program 'sparc-rtems6-gcc'  : 
/opt/rtems/6/bin/sparc-rtems6-gcc
Checking for program 'sparc-rtems6-g++'  : 
/opt/rtems/6/bin/sparc-rtems6-g++

Checking for program 'sparc-rtems6-ar'   : /opt/rtems/6/bin/sparc-rtems6-ar
Checking for program 'sparc-rtems6-ld'   : /opt/rtems/6/bin/sparc-rtems6-ld
Checking for program 'ar'    : /opt/rtems/6/bin/sparc-rtems6-ar
Checking for program 'g++, c++'  : 
/opt/rtems/6/bin/sparc-rtems6-g++

Checking for program 'ar'    : /opt/rtems/6/bin/sparc-rtems6-ar
Checking for program 'gas, gcc'  : 
/opt/rtems/6/bin/sparc-rtems6-gcc

Checking for program 'ar'    : /opt/rtems/6/bin/sparc-rtems6-ar
Checking for program 'gcc, cc'   : 
/opt/rtems/6/bin/sparc-rtems6-gcc

Checking for program 'ar'    : /opt/rtems/6/bin/sparc-rtems6-ar
Checking for asm flags '-MMD'    : yes
Checking for c flags '-MMD'  : yes
Checking for cxx flags '-MMD'    : yes
Traceback (most recent call last):
  File 
"/home/EB/sebastian_h/src/rtems/.waf-2.0.20-36f5354d605298f6a89c09e0c7ef6c1d/waflib/Scripting.py", 
line 119, in waf_entry_point

    run_commands()
  File 
"/home/EB/sebastian_h/src/rtems/.waf-2.0.20-36f5354d605298f6a89c09e0c7ef6c1d/waflib/Scripting.py", 
line 182, in run_commands

    ctx=run_command(cmd_name)
  File 
"/home/EB/sebastian_h/src/rtems/.waf-2.0.20-36f5354d605298f6a89c09e0c7ef6c1d/waflib/Scripting.py", 
line 173, in run_command

    ctx.execute()
  File 
"/home/EB/sebastian_h/src/rtems/.waf-2.0.20-36f5354d605298f6a89c09e0c7ef6c1d/waflib/Configure.py", 
line 101, in execute

    env.store(os.path.join(Context.run_dir,Options.lockfile))
  File 
"/home/EB/sebastian_h/src/rtems/.waf-2.0.20-36f5354d605298f6a89c09e0c7ef6c1d/waflib/ConfigSet.py", 
line 146, in store

    Utils.writef(filename,''.join(buf))
  File 
"/home/EB/sebastian_h/src/rtems/.waf-2.0.20-36f5354d605298f6a89c09e0c7ef6c1d/waflib/Utils.py", 
line 160, in writef

    with open(fname,m)as f:
IOError: [Errno 13] Permission denied: 
'/home/EB/sebastian_h/src/rtems-read-only/.lock-waf_linux2_build'


--
embedded brains GmbH
Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
Phone: +49-89-18 94 741 - 16
Fax:   +49-89-18 94 741 - 08
PGP: Public key available on request.

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

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

[PATCH 0/4] Add header file conventions

[Sebastian Huber]

This patch set adds header file conventions and clarifies some parts.

Sebastian Huber (4):
  eng: Remove "Generating a Tools Patch"
  eng: Add header file conventions
  eng: Clarify "Source Documentation" section
  eng: Clarify "Coding Conventions" introduction

 eng/coding-conventions.rst | 74 ++
 eng/coding-doxygen.rst |  2 ++
 eng/coding-file-hdr.rst|  4 +++
 eng/coding-gen-patch.rst   | 35 --
 eng/coding.rst |  1 -
 5 files changed, 65 insertions(+), 51 deletions(-)
 delete mode 100644 eng/coding-gen-patch.rst

-- 
2.26.2

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

[PATCH 4/4] eng: Clarify "Coding Conventions" introduction

[Sebastian Huber]

---
 eng/coding-conventions.rst | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/eng/coding-conventions.rst b/eng/coding-conventions.rst
index 5dd8df5..e34cd74 100644
--- a/eng/coding-conventions.rst
+++ b/eng/coding-conventions.rst
@@ -9,11 +9,11 @@
 Coding Conventions
 **
 
-The style of RTEMS is generally consistent in the core areas.
-This page attempts to capture generally accepted practices.
-When in doubt, consult the code around you or look in cpukit/rtems.
-See the sister page `Doxygen Recommendations 
`_.
-for examples that illustrate style rules and Doxygen usage.
+The style of RTEMS is generally consistent in the core areas.  This section
+attempts to capture generally accepted practices.  When in doubt, consult the
+code around you, look in the RTEMS sources in the directories
+:file:`cpukit/include/rtems/score` and :file:`cpukit/score`, or ask on the
+:r:list:`devel`.
 
 Source Documentation
 
-- 
2.26.2

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

[PATCH 2/4] eng: Add header file conventions

[Sebastian Huber]

---
 eng/coding-conventions.rst | 37 +
 eng/coding-doxygen.rst |  2 ++
 eng/coding-file-hdr.rst|  2 ++
 3 files changed, 41 insertions(+)

diff --git a/eng/coding-conventions.rst b/eng/coding-conventions.rst
index b85d8fc..e7a67ec 100644
--- a/eng/coding-conventions.rst
+++ b/eng/coding-conventions.rst
@@ -251,6 +251,43 @@ Miscellaneous
 * If adding code to ''cpukit'' be sure the filename is unique since
   all files under that directory get merged into a single library.
 
+Header Files
+
+
+* Do not add top-level header files.  Place the header files in a directory,
+  for example ``#include ``, ``#include ``,
+  ``#include ``, etc.
+
+* Use the extension :file:`.h` for C header files.
+
+* Use the extension :file:`.hpp` for C++ header files.
+
+* Use the file template for header files, see :ref:`CCXXHeaderFileTemplate`.
+
+* Use separate header files for the API and the implementation.
+
+* Use :file:`foobar.h` for the header file of the ``foobar`` module which
+  defines API components.
+
+* Use :file:`foobardata.h` for the header file of the ``foobar`` module which
+  defines interfaces used by the application configuration.
+
+* Use :file:`foobarimpl.h` for the header file of the ``foobar`` module which
+  defines interfaces, macros, and inline functions used by the implementation.
+
+* Do not place inline functions which are only used in one implementation
+  source file into the implementation header file.  Add these inline functions
+  directly to the corresponding source file.
+
+* Document all elements in header files with comments in Doxygen markup, see
+  :ref:`DoxygenGuidelines`.
+
+* Only place header files which should be directly included by the user with an
+  ``@file`` Doxygen directive into the API documentation group.  Place internal
+  API header files with an ``@file`` Doxygen command into the implementation
+  documentation group even if they define API elements.  The API documentation
+  group should only list public header files and no internal header files.
+
 Layering
 
 
diff --git a/eng/coding-doxygen.rst b/eng/coding-doxygen.rst
index 2f7682d..f4308ef 100644
--- a/eng/coding-doxygen.rst
+++ b/eng/coding-doxygen.rst
@@ -2,6 +2,8 @@
 
 .. Copyright (C) 2019 embedded brains GmbH
 
+.. _DoxygenGuidelines:
+
 Doxygen Guidelines
 ==
 
diff --git a/eng/coding-file-hdr.rst b/eng/coding-file-hdr.rst
index 64eeec3..053e01e 100644
--- a/eng/coding-file-hdr.rst
+++ b/eng/coding-file-hdr.rst
@@ -72,6 +72,8 @@ Check the top-level :file:`COPYING` file of the repository.  
If you are a new
 copyright holder, then add yourself to the top of the list.  If your last year
 of a substantial contribution changed, then please update your copyright line.
 
+.. _CCXXHeaderFileTemplate:
+
 C/C++ Header File Template
 --
 
-- 
2.26.2

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

[PATCH 1/4] eng: Remove "Generating a Tools Patch"

[Sebastian Huber]

This section is probably some left over stuff from CVS times.  The topic
is already covered by the "Software Development (Git Users)" section.
---
 eng/coding-gen-patch.rst | 35 ---
 eng/coding.rst   |  1 -
 2 files changed, 36 deletions(-)
 delete mode 100644 eng/coding-gen-patch.rst

diff --git a/eng/coding-gen-patch.rst b/eng/coding-gen-patch.rst
deleted file mode 100644
index 1781d89..000
--- a/eng/coding-gen-patch.rst
+++ /dev/null
@@ -1,35 +0,0 @@
-.. SPDX-License-Identifier: CC-BY-SA-4.0
-
-.. Copyright (C) 2018.
-.. COMMENT: RTEMS Foundation, The RTEMS Documentation Project
-
-Generating a Tools Patch
-
-
-.. COMMENT:TBD - Convert the following to Rest and insert into this file
-.. COMMENT:TBD - https://devel.rtems.org/wiki/Developer/Coding/GenerateAPatch
-
-The RTEMS patches to the development tools are generated using a command like 
this
-
-.. code block:: shell
-  diff -N -P -r -c TOOL-original-image TOOL-with-changes >PATCHFILE
-
-where the options are:
-
-* -N and -P take care of adding and removing files (be careful not to
-include junk files like file.mybackup)
-
-* -r tells diff to recurse through subdirectories
-* -c is a context diff (easy to read for humans)
-* -u is a unified diff (easy for patch to apply)
-
-Please look at the generated PATCHFILE and make sure it does not contain
-anything you did not intend to send to the maintainers. It is easy to
-accidentally leave a backup file in the modified source tree or have a
-spurious change that should not be in the PATCHFILE.
-
-If you end up with the entire contents of a file in the patch and can't
-figure out why, you may have different CR/LF scheme in the two source
-files. The GNU open-source packages usually have UNIX style CR/LF. If
-you edit on a Windows platform, the line terminators may have been
-transformed by the editor into Windows style.
diff --git a/eng/coding.rst b/eng/coding.rst
index decadea..6cba22a 100644
--- a/eng/coding.rst
+++ b/eng/coding.rst
@@ -16,5 +16,4 @@ TBD  - Write introduction, re-order, identify missing content
 coding-deprecating
 coding-doxygen
 coding-file-hdr
-coding-gen-patch
 coding-naming
-- 
2.26.2

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

[PATCH 3/4] eng: Clarify "Source Documentation" section

[Sebastian Huber]

---
 eng/coding-conventions.rst | 27 +--
 eng/coding-file-hdr.rst|  2 ++
 2 files changed, 19 insertions(+), 10 deletions(-)

diff --git a/eng/coding-conventions.rst b/eng/coding-conventions.rst
index e7a67ec..5dd8df5 100644
--- a/eng/coding-conventions.rst
+++ b/eng/coding-conventions.rst
@@ -18,17 +18,24 @@ for examples that illustrate style rules and Doxygen usage.
 Source Documentation
 
 
-* Use Doxygen according to our `Doxygen Recommendations 
`_..
-* Start each file with a brief description followed by a license.
-  See `Boilerplate File Header 
`_..
+* Use Doxygen according to our :ref:`DoxygenGuidelines`.
+
+* Use the file templates, see :ref:`FileTemplates`.
+
 * Use ``/* */`` comments.
-* Use comments wisely within function bodies, to explain
-  or draw attention without being verbose.
-* Use English prose and strive for good grammar,
-  spelling, and punctuation.
-* Use TODO: with a comment to indicate code that needs improvement.
-  Make it clear what there is to do.
-* Use XXX or FIXME to indicate an error/bug/broken code.
+
+* Do not use ``//`` comments.
+
+* Use comments wisely within function bodies, to explain or draw attention
+  without being verbose.
+
+* Use English prose and strive for good grammar, spelling, and punctuation.
+
+* Use ``TODO`` with a comment to indicate code that needs improvement.  Make
+  it clear what there is to do.  Add a ticket and add a link to it.
+
+* Use ``XXX`` or ``FIXME`` to indicate an error/bug/broken code.  Add a ticket
+  and add a link to it.
 
 Licenses
 
diff --git a/eng/coding-file-hdr.rst b/eng/coding-file-hdr.rst
index 053e01e..caac2f7 100644
--- a/eng/coding-file-hdr.rst
+++ b/eng/coding-file-hdr.rst
@@ -3,6 +3,8 @@
 .. Copyright (C) 2018, 2020 embedded brains GmbH 
(http://www.embedded-brains.de)
 .. Copyright (C) 2018, 2020 Sebastian Huber
 
+.. _FileTemplates:
+
 File Templates
 ==
 
-- 
2.26.2

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

Re: 80 or 79 characters limit?

[Christian Mauderer]

Hello Joel and Sebastian,

On 05/11/2020 16:44, Joel Sherrill wrote:
> 
> 
> On Thu, Nov 5, 2020, 9:26 AM Sebastian Huber
>  > wrote:
> 
> Hello,
> 
> I review currently the Coding Conventions. Should the 80 characters
> limit be really a 79 characters limit with the \n as the invisible 80th
> character?
> 
> 
> Yes. 
> 
> As old as this makes me feel, I remember printers which did an automatic
> linefeed and then the newline one if you hit column 80. So it really is
> 79 unfortunately.

I don't think printers with an automatic linefeed are a common use case
for reading the RTEMS source code nowadays. So that maybe isn't the best
reason for using 79 characters.

I would suggest to use the same convention that most coding styles use
which seems to be 80 characters:

  https://en.wikipedia.org/wiki/Characters_per_line#In_programming

At least if there are no more recent examples for tools or editors where
79 is a benefit. 80 seems just feels a bit more natural.

By the way: If we count '\n': Should we count a tab '\t' as a single
character, as 2, as 4 or as 8 ones? What about the few Unicode
characters that slipped in over the years?

Best regards

Christian

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

Re: 80 or 79 characters limit?

[Joel Sherrill]

On Thu, Nov 5, 2020, 1:12 PM Christian Mauderer  wrote:

> Hello Joel and Sebastian,
>
> On 05/11/2020 16:44, Joel Sherrill wrote:
> >
> >
> > On Thu, Nov 5, 2020, 9:26 AM Sebastian Huber
> >  > > wrote:
> >
> > Hello,
> >
> > I review currently the Coding Conventions. Should the 80 characters
> > limit be really a 79 characters limit with the \n as the invisible
> 80th
> > character?
> >
> >
> > Yes.
> >
> > As old as this makes me feel, I remember printers which did an automatic
> > linefeed and then the newline one if you hit column 80. So it really is
> > 79 unfortunately.
>
> I don't think printers with an automatic linefeed are a common use case
> for reading the RTEMS source code nowadays. So that maybe isn't the best
> reason for using 79 characters.
>

+1

>
> I would suggest to use the same convention that most coding styles use
> which seems to be 80 characters:
>
>   https://en.wikipedia.org/wiki/Characters_per_line#In_programming
>
> At least if there are no more recent examples for tools or editors where
> 79 is a benefit. 80 seems just feels a bit more natural.


> By the way: If we count '\n': Should we count a tab '\t' as a single
> character, as 2, as 4 or as 8 ones?


We shouldn't have tabs in code we own.

What about the few Unicode
> characters that slipped in over the years?
>

We also shouldn't have unicode characters randomly floating around. They
tend to pop up in my experience when people copy from word processors and
get fancy quotes. Those cases should be eliminated


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

Re: 80 or 79 characters limit?

[Christian Mauderer]

Hello Joel,

On 05/11/2020 20:15, Joel Sherrill wrote:
> 
> 
> On Thu, Nov 5, 2020, 1:12 PM Christian Mauderer  > wrote:
> 
> Hello Joel and Sebastian,
> 
> On 05/11/2020 16:44, Joel Sherrill wrote:
> >
> >
> > On Thu, Nov 5, 2020, 9:26 AM Sebastian Huber
> >  
> >  >> wrote:
> >
> >     Hello,
> >
> >     I review currently the Coding Conventions. Should the 80
> characters
> >     limit be really a 79 characters limit with the \n as the
> invisible 80th
> >     character?
> >
> >
> > Yes. 
> >
> > As old as this makes me feel, I remember printers which did an
> automatic
> > linefeed and then the newline one if you hit column 80. So it
> really is
> > 79 unfortunately.
> 
> I don't think printers with an automatic linefeed are a common use case
> for reading the RTEMS source code nowadays. So that maybe isn't the best
> reason for using 79 characters.
> 
> 
> +1
> 
> 
> I would suggest to use the same convention that most coding styles use
> which seems to be 80 characters:
> 
>   https://en.wikipedia.org/wiki/Characters_per_line#In_programming
> 
> At least if there are no more recent examples for tools or editors where
> 79 is a benefit. 80 seems just feels a bit more natural.
> 
> 
> By the way: If we count '\n': Should we count a tab '\t' as a single
> character, as 2, as 4 or as 8 ones?
> 
> 
> We shouldn't have tabs in code we own.

Good point.

> 
> What about the few Unicode
> characters that slipped in over the years?
> 
> 
> We also shouldn't have unicode characters randomly floating around. They
> tend to pop up in my experience when people copy from word processors
> and get fancy quotes. Those cases should be eliminated

Last time I stumbled across a tool that didn't like unicode characters I
found about 75 lines in RTEMS with unicode characters. I have been to
lazy to fix them back then. Mostly because some of them would have
needed some thought about what there should have been (I assume it has
been a microsecond in some cases, but still not sure). Attached you can
find a patch that should replaces most of them without much thought
about the content. If you think it's useful, I can polish it up a bit.

Best regards

Christian

> 
> 
> Best regards
> 
> Christian
> 
> >
> >
> >     --
> >     embedded brains GmbH
> >     Sebastian HUBER
> >     Dornierstr. 4
> >     82178 Puchheim
> >     Germany
> >     email: sebastian.hu...@embedded-brains.de
> 
> >      >
> >     Phone: +49-89-18 94 741 - 16
> >     Fax:   +49-89-18 94 741 - 08
> >     PGP: Public key available on request.
> >
> >     embedded brains GmbH
> >     Registergericht: Amtsgericht München
> >     Registernummer: HRB 157899
> >     Vertretungsberechtigte Geschäftsführer: Peter Rasmussen,
> Thomas Dörfler
> >     Unsere Datenschutzerklärung finden Sie hier:
> >     https://embedded-brains.de/datenschutzerklaerung/
> >
> >     ___
> >     devel mailing list
> >     devel@rtems.org 
> >
> >     http://lists.rtems.org/mailman/listinfo/devel
> >
> >
> > ___
> > devel mailing list
> > devel@rtems.org 
> > http://lists.rtems.org/mailman/listinfo/devel
> >
> 
>From 0c216e723e10acbf1f4c9f28044e19ff408d8fab Mon Sep 17 00:00:00 2001
From: Christian Mauderer 
Date: Thu, 1 Oct 2020 23:15:33 +0200
Subject: [PATCH] Remove special chars.

---
 bsps/arm/atsam/contrib/libraries/libboard/include/gmii.h  | 2 +-
 .../contrib/libraries/libboard/source/board_memories.c| 8 
 bsps/arm/atsam/contrib/libraries/libchip/source/aes.c | 2 +-
 bsps/arm/atsam/contrib/libraries/libchip/source/sdramc.c  | 2 +-
 bsps/arm/lm3s69xx/console/console-config.c| 2 +-
 bsps/arm/lm3s69xx/console/uart.c  | 2 +-
 bsps/arm/lm3s69xx/i2c/ssi.c   | 2 +-
 bsps/arm/lm3s69xx/include/bsp/io.h| 2 +-
 bsps/arm/lm3s69xx/include/bsp/irq.h   | 2 +-
 bsps/arm/lm3s69xx/include/bsp/lm3s69xx.h  | 2 +-
 bsps/arm/lm3s69xx/include/bsp/ssi.h   | 2 +-
 bsps/arm/lm3s69xx/include/bsp/syscon.h| 2 +-
 bsps/arm/lm3s69xx/start/bspstart.c| 4 ++--
 bsps/arm/lm3s69xx/start/io.c  | 2 +-
 bsps/arm/lm3s69xx/start/s

Re: 80 or 79 characters limit?

[Joel Sherrill]

I tried at one point to figure out how to script the changes when I ran
into them.
But it was easier to fix them by hand. If you have a simple script, it
would be good
to have a home for it. We could grow it then.

Not accepting unicode should be checked for patches and should be in
Coding Conventions.

I think you made a couple of bad mapping choices.

- "(r)" for the registered symbol (circle R)
-  "u" for the micro Greek letter in usec and us (which is strange for usec)

Some I have no idea about.

+ aes.c - absolutely no idea
+ rtl22xx/console/uart.c - maybe an x
+ powerpc/include/mpc83xx/mpc83xx.h - maybe an x

I think a patch series doing copyright symbols, (r), and u for micro
as individual changes would eliminate a lot and not be controversial.
That should leave the remaining for a second pass.

One patch per character change is safer to review.

--joel


On Thu, Nov 5, 2020 at 1:34 PM Christian Mauderer  wrote:

> Hello Joel,
>
> On 05/11/2020 20:15, Joel Sherrill wrote:
> >
> >
> > On Thu, Nov 5, 2020, 1:12 PM Christian Mauderer  > > wrote:
> >
> > Hello Joel and Sebastian,
> >
> > On 05/11/2020 16:44, Joel Sherrill wrote:
> > >
> > >
> > > On Thu, Nov 5, 2020, 9:26 AM Sebastian Huber
> > >  > 
> > >  > >> wrote:
> > >
> > > Hello,
> > >
> > > I review currently the Coding Conventions. Should the 80
> > characters
> > > limit be really a 79 characters limit with the \n as the
> > invisible 80th
> > > character?
> > >
> > >
> > > Yes.
> > >
> > > As old as this makes me feel, I remember printers which did an
> > automatic
> > > linefeed and then the newline one if you hit column 80. So it
> > really is
> > > 79 unfortunately.
> >
> > I don't think printers with an automatic linefeed are a common use
> case
> > for reading the RTEMS source code nowadays. So that maybe isn't the
> best
> > reason for using 79 characters.
> >
> >
> > +1
> >
> >
> > I would suggest to use the same convention that most coding styles
> use
> > which seems to be 80 characters:
> >
> >   https://en.wikipedia.org/wiki/Characters_per_line#In_programming
> >
> > At least if there are no more recent examples for tools or editors
> where
> > 79 is a benefit. 80 seems just feels a bit more natural.
> >
> >
> > By the way: If we count '\n': Should we count a tab '\t' as a single
> > character, as 2, as 4 or as 8 ones?
> >
> >
> > We shouldn't have tabs in code we own.
>
> Good point.
>
> >
> > What about the few Unicode
> > characters that slipped in over the years?
> >
> >
> > We also shouldn't have unicode characters randomly floating around. They
> > tend to pop up in my experience when people copy from word processors
> > and get fancy quotes. Those cases should be eliminated
>
> Last time I stumbled across a tool that didn't like unicode characters I
> found about 75 lines in RTEMS with unicode characters. I have been to
> lazy to fix them back then. Mostly because some of them would have
> needed some thought about what there should have been (I assume it has
> been a microsecond in some cases, but still not sure). Attached you can
> find a patch that should replaces most of them without much thought
> about the content. If you think it's useful, I can polish it up a bit.
>
> Best regards
>
> Christian
>
> >
> >
> > Best regards
> >
> > Christian
> >
> > >
> > >
> > > --
> > > embedded brains GmbH
> > > Sebastian HUBER
> > > Dornierstr. 4
> > > 82178 Puchheim
> > > Germany
> > > email: sebastian.hu...@embedded-brains.de
> > 
> > >  > >
> > > Phone: +49-89-18 94 741 - 16
> > > Fax:   +49-89-18 94 741 - 08
> > > PGP: Public key available on request.
> > >
> > > embedded brains GmbH
> > > Registergericht: Amtsgericht München
> > > Registernummer: HRB 157899
> > > Vertretungsberechtigte Geschäftsführer: Peter Rasmussen,
> > Thomas Dörfler
> > > Unsere Datenschutzerklärung finden Sie hier:
> > > https://embedded-brains.de/datenschutzerklaerung/
> > >
> > > ___
> > > devel mailing list
> > > devel@rtems.org 
> > >
> > > http://lists.rtems.org/mailman/listinfo/devel
> > >
> > >
> > > ___
> > > devel mailing list
> > > devel@rtems.org 
> > > http://lists.rtems.org/mailman/list

Re: 80 or 79 characters limit?

[Gedare Bloom]

On Thu, Nov 5, 2020 at 1:14 PM Joel Sherrill  wrote:
>
> I tried at one point to figure out how to script the changes when I ran into 
> them.
> But it was easier to fix them by hand. If you have a simple script, it would 
> be good
> to have a home for it. We could grow it then.
>
> Not accepting unicode should be checked for patches and should be in
> Coding Conventions.
>
> I think you made a couple of bad mapping choices.
>
> - "(r)" for the registered symbol (circle R)
> -  "u" for the micro Greek letter in usec and us (which is strange for usec)
>
> Some I have no idea about.
>
> + aes.c - absolutely no idea
> + rtl22xx/console/uart.c - maybe an x
> + powerpc/include/mpc83xx/mpc83xx.h - maybe an x
>
> I think a patch series doing copyright symbols, (r), and u for micro
> as individual changes would eliminate a lot and not be controversial.
> That should leave the remaining for a second pass.
>
> One patch per character change is safer to review.
"per kind of character"

feel free to send all the (C) together, etc.

I think the AES one is pTq, math notation for a vector product using transpose.

I used https://www.branah.com/unicode-converter and put the UTF-8 we
have in our repo in the box, and that gives some idea what it should
be in the top unicode box. i.e., put "¡°T¡±" in the UTF-8 box and see
what pops out on top

>
> --joel
>
>
> On Thu, Nov 5, 2020 at 1:34 PM Christian Mauderer  wrote:
>>
>> Hello Joel,
>>
>> On 05/11/2020 20:15, Joel Sherrill wrote:
>> >
>> >
>> > On Thu, Nov 5, 2020, 1:12 PM Christian Mauderer > > > wrote:
>> >
>> > Hello Joel and Sebastian,
>> >
>> > On 05/11/2020 16:44, Joel Sherrill wrote:
>> > >
>> > >
>> > > On Thu, Nov 5, 2020, 9:26 AM Sebastian Huber
>> > > > > 
>> > > > > >> wrote:
>> > >
>> > > Hello,
>> > >
>> > > I review currently the Coding Conventions. Should the 80
>> > characters
>> > > limit be really a 79 characters limit with the \n as the
>> > invisible 80th
>> > > character?
>> > >
>> > >
>> > > Yes.
>> > >
>> > > As old as this makes me feel, I remember printers which did an
>> > automatic
>> > > linefeed and then the newline one if you hit column 80. So it
>> > really is
>> > > 79 unfortunately.
>> >
>> > I don't think printers with an automatic linefeed are a common use case
>> > for reading the RTEMS source code nowadays. So that maybe isn't the 
>> > best
>> > reason for using 79 characters.
>> >
>> >
>> > +1
>> >
>> >
>> > I would suggest to use the same convention that most coding styles use
>> > which seems to be 80 characters:
>> >
>> >   https://en.wikipedia.org/wiki/Characters_per_line#In_programming
>> >
>> > At least if there are no more recent examples for tools or editors 
>> > where
>> > 79 is a benefit. 80 seems just feels a bit more natural.
>> >
>> >
>> > By the way: If we count '\n': Should we count a tab '\t' as a single
>> > character, as 2, as 4 or as 8 ones?
>> >
>> >
>> > We shouldn't have tabs in code we own.
>>
>> Good point.
>>
>> >
>> > What about the few Unicode
>> > characters that slipped in over the years?
>> >
>> >
>> > We also shouldn't have unicode characters randomly floating around. They
>> > tend to pop up in my experience when people copy from word processors
>> > and get fancy quotes. Those cases should be eliminated
>>
>> Last time I stumbled across a tool that didn't like unicode characters I
>> found about 75 lines in RTEMS with unicode characters. I have been to
>> lazy to fix them back then. Mostly because some of them would have
>> needed some thought about what there should have been (I assume it has
>> been a microsecond in some cases, but still not sure). Attached you can
>> find a patch that should replaces most of them without much thought
>> about the content. If you think it's useful, I can polish it up a bit.
>>
>> Best regards
>>
>> Christian
>>
>> >
>> >
>> > Best regards
>> >
>> > Christian
>> >
>> > >
>> > >
>> > > --
>> > > embedded brains GmbH
>> > > Sebastian HUBER
>> > > Dornierstr. 4
>> > > 82178 Puchheim
>> > > Germany
>> > > email: sebastian.hu...@embedded-brains.de
>> > 
>> > > > > >
>> > > Phone: +49-89-18 94 741 - 16
>> > > Fax:   +49-89-18 94 741 - 08
>> > > PGP: Public key available on request.
>> > >
>> > > embedded brains GmbH
>> > > Registergericht: Amtsgericht München
>> > > Registernummer: HRB 157899
>> > > Vertretungsberechtigte Geschäftsführer: Peter Rasmussen,
>> > Thomas Dörfler

Re: 80 or 79 characters limit?

[Joel Sherrill]

On Thu, Nov 5, 2020 at 2:28 PM Gedare Bloom  wrote:

> On Thu, Nov 5, 2020 at 1:14 PM Joel Sherrill  wrote:
> >
> > I tried at one point to figure out how to script the changes when I ran
> into them.
> > But it was easier to fix them by hand. If you have a simple script, it
> would be good
> > to have a home for it. We could grow it then.
> >
> > Not accepting unicode should be checked for patches and should be in
> > Coding Conventions.
> >
> > I think you made a couple of bad mapping choices.
> >
> > - "(r)" for the registered symbol (circle R)
> > -  "u" for the micro Greek letter in usec and us (which is strange for
> usec)
> >
> > Some I have no idea about.
> >
> > + aes.c - absolutely no idea
> > + rtl22xx/console/uart.c - maybe an x
> > + powerpc/include/mpc83xx/mpc83xx.h - maybe an x
> >
> > I think a patch series doing copyright symbols, (r), and u for micro
> > as individual changes would eliminate a lot and not be controversial.
> > That should leave the remaining for a second pass.
> >
> > One patch per character change is safer to review.
> "per kind of character"
>
> feel free to send all the (C) together, etc.
>

+1

>
> I think the AES one is pTq, math notation for a vector product using
> transpose.
>
> I used https://www.branah.com/unicode-converter and put the UTF-8 we
> have in our repo in the box, and that gives some idea what it should
> be in the top unicode box. i.e., put "¡°T¡±" in the UTF-8 box and see
> what pops out on top
>

I was hoping you weren't rickrolling us but that's a neat site. :)

I think your translation is right.

--joel

>
> >
> > --joel
> >
> >
> > On Thu, Nov 5, 2020 at 1:34 PM Christian Mauderer 
> wrote:
> >>
> >> Hello Joel,
> >>
> >> On 05/11/2020 20:15, Joel Sherrill wrote:
> >> >
> >> >
> >> > On Thu, Nov 5, 2020, 1:12 PM Christian Mauderer  >> > > wrote:
> >> >
> >> > Hello Joel and Sebastian,
> >> >
> >> > On 05/11/2020 16:44, Joel Sherrill wrote:
> >> > >
> >> > >
> >> > > On Thu, Nov 5, 2020, 9:26 AM Sebastian Huber
> >> > >  >> > 
> >> > >  >> > >> wrote:
> >> > >
> >> > > Hello,
> >> > >
> >> > > I review currently the Coding Conventions. Should the 80
> >> > characters
> >> > > limit be really a 79 characters limit with the \n as the
> >> > invisible 80th
> >> > > character?
> >> > >
> >> > >
> >> > > Yes.
> >> > >
> >> > > As old as this makes me feel, I remember printers which did an
> >> > automatic
> >> > > linefeed and then the newline one if you hit column 80. So it
> >> > really is
> >> > > 79 unfortunately.
> >> >
> >> > I don't think printers with an automatic linefeed are a common
> use case
> >> > for reading the RTEMS source code nowadays. So that maybe isn't
> the best
> >> > reason for using 79 characters.
> >> >
> >> >
> >> > +1
> >> >
> >> >
> >> > I would suggest to use the same convention that most coding
> styles use
> >> > which seems to be 80 characters:
> >> >
> >> >
> https://en.wikipedia.org/wiki/Characters_per_line#In_programming
> >> >
> >> > At least if there are no more recent examples for tools or
> editors where
> >> > 79 is a benefit. 80 seems just feels a bit more natural.
> >> >
> >> >
> >> > By the way: If we count '\n': Should we count a tab '\t' as a
> single
> >> > character, as 2, as 4 or as 8 ones?
> >> >
> >> >
> >> > We shouldn't have tabs in code we own.
> >>
> >> Good point.
> >>
> >> >
> >> > What about the few Unicode
> >> > characters that slipped in over the years?
> >> >
> >> >
> >> > We also shouldn't have unicode characters randomly floating around.
> They
> >> > tend to pop up in my experience when people copy from word processors
> >> > and get fancy quotes. Those cases should be eliminated
> >>
> >> Last time I stumbled across a tool that didn't like unicode characters I
> >> found about 75 lines in RTEMS with unicode characters. I have been to
> >> lazy to fix them back then. Mostly because some of them would have
> >> needed some thought about what there should have been (I assume it has
> >> been a microsecond in some cases, but still not sure). Attached you can
> >> find a patch that should replaces most of them without much thought
> >> about the content. If you think it's useful, I can polish it up a bit.
> >>
> >> Best regards
> >>
> >> Christian
> >>
> >> >
> >> >
> >> > Best regards
> >> >
> >> > Christian
> >> >
> >> > >
> >> > >
> >> > > --
> >> > > embedded brains GmbH
> >> > > Sebastian HUBER
> >> > > Dornierstr. 4
> >> > > 82178 Puchheim
> >> > > Germany
> >> > > email: sebastian.hu...@embedded-brains.de
> >> > 
> >> > > 

Re: 80 or 79 characters limit?

[Christian Mauderer]

On 05/11/2020 21:28, Gedare Bloom wrote:
> On Thu, Nov 5, 2020 at 1:14 PM Joel Sherrill  wrote:
>>
>> I tried at one point to figure out how to script the changes when I ran into 
>> them.
>> But it was easier to fix them by hand. If you have a simple script, it would 
>> be good
>> to have a home for it. We could grow it then.

Sorry, I didn't use a script either. I just wanted to try a tool on a
larger code base and blindly removed everything that has been a problem
for it.

>>
>> Not accepting unicode should be checked for patches and should be in
>> Coding Conventions.
>>
>> I think you made a couple of bad mapping choices.

See above: The target was not to have a good choice but just to get rid
of them. Never intended to create a real patch from it. But like I said:
I'll polish it a bit and send patches.

>>
>> - "(r)" for the registered symbol (circle R)
>> -  "u" for the micro Greek letter in usec and us (which is strange for usec)

For me "s" is a quite common short for seconds. And u is quite common
for replacing a micro if there is no special micro character. Most
likely in English there is a higher chance to mis-read it as an "us"
like the one in "tell us something" and therefore the short form is
considered strange ;-)

>>
>> Some I have no idea about.
>>
>> + aes.c - absolutely no idea
>> + rtl22xx/console/uart.c - maybe an x
>> + powerpc/include/mpc83xx/mpc83xx.h - maybe an x
>>
>> I think a patch series doing copyright symbols, (r), and u for micro
>> as individual changes would eliminate a lot and not be controversial.
>> That should leave the remaining for a second pass.
>>
>> One patch per character change is safer to review.
> "per kind of character"
> 
> feel free to send all the (C) together, etc.

OK.

> 
> I think the AES one is pTq, math notation for a vector product using 
> transpose.
> 
> I used https://www.branah.com/unicode-converter and put the UTF-8 we
> have in our repo in the box, and that gives some idea what it should
> be in the top unicode box. i.e., put "¡°T¡±" in the UTF-8 box and see
> what pops out on top

That's a nice tool. Thanks for the hint.

Best regards

Christian

> 
>>
>> --joel
>>
>>
>> On Thu, Nov 5, 2020 at 1:34 PM Christian Mauderer  wrote:
>>>
>>> Hello Joel,
>>>
>>> On 05/11/2020 20:15, Joel Sherrill wrote:


 On Thu, Nov 5, 2020, 1:12 PM Christian Mauderer >>> > wrote:

 Hello Joel and Sebastian,

 On 05/11/2020 16:44, Joel Sherrill wrote:
 >
 >
 > On Thu, Nov 5, 2020, 9:26 AM Sebastian Huber
 > >>> 
 > >> wrote:
 >
 > Hello,
 >
 > I review currently the Coding Conventions. Should the 80
 characters
 > limit be really a 79 characters limit with the \n as the
 invisible 80th
 > character?
 >
 >
 > Yes.
 >
 > As old as this makes me feel, I remember printers which did an
 automatic
 > linefeed and then the newline one if you hit column 80. So it
 really is
 > 79 unfortunately.

 I don't think printers with an automatic linefeed are a common use case
 for reading the RTEMS source code nowadays. So that maybe isn't the 
 best
 reason for using 79 characters.


 +1


 I would suggest to use the same convention that most coding styles use
 which seems to be 80 characters:

   https://en.wikipedia.org/wiki/Characters_per_line#In_programming

 At least if there are no more recent examples for tools or editors 
 where
 79 is a benefit. 80 seems just feels a bit more natural.


 By the way: If we count '\n': Should we count a tab '\t' as a single
 character, as 2, as 4 or as 8 ones?


 We shouldn't have tabs in code we own.
>>>
>>> Good point.
>>>

 What about the few Unicode
 characters that slipped in over the years?


 We also shouldn't have unicode characters randomly floating around. They
 tend to pop up in my experience when people copy from word processors
 and get fancy quotes. Those cases should be eliminated
>>>
>>> Last time I stumbled across a tool that didn't like unicode characters I
>>> found about 75 lines in RTEMS with unicode characters. I have been to
>>> lazy to fix them back then. Mostly because some of them would have
>>> needed some thought about what there should have been (I assume it has
>>> been a microsecond in some cases, but still not sure). Attached you can
>>> find a patch that should replaces most of them without much thought
>>> about the content. If you think it's useful, I can polish it up a bit.
>>>
>>> Best regards
>>>
>>> Christian
>>>


 B

Re: 80 or 79 characters limit?

[Joel Sherrill]

On Thu, Nov 5, 2020 at 2:42 PM Christian Mauderer  wrote:

> On 05/11/2020 21:28, Gedare Bloom wrote:
> > On Thu, Nov 5, 2020 at 1:14 PM Joel Sherrill  wrote:
> >>
> >> I tried at one point to figure out how to script the changes when I ran
> into them.
> >> But it was easier to fix them by hand. If you have a simple script, it
> would be good
> >> to have a home for it. We could grow it then.
>
> Sorry, I didn't use a script either. I just wanted to try a tool on a
> larger code base and blindly removed everything that has been a problem
> for it.
>

Well this is a challenge for another day. We can always use file and if
gives the wrong answer, then we know something is broken in the file.


>
> >>
> >> Not accepting unicode should be checked for patches and should be in
> >> Coding Conventions.
> >>
> >> I think you made a couple of bad mapping choices.
>
> See above: The target was not to have a good choice but just to get rid
> of them. Never intended to create a real patch from it. But like I said:
> I'll polish it a bit and send patches.
>

Thanks.

>
> >>
> >> - "(r)" for the registered symbol (circle R)
> >> -  "u" for the micro Greek letter in usec and us (which is strange for
> usec)
>
> For me "s" is a quite common short for seconds. And u is quite common
> for replacing a micro if there is no special micro character. Most
> likely in English there is a higher chance to mis-read it as an "us"
> like the one in "tell us something" and therefore the short form is
> considered strange ;-)
>

I have seen people use msec or ms for microsecond and that is wrong.
I tend to like to see millisecond and microsecond spelled out unless
there is a really good reason not to. Usually there is plenty of space to
hedge on the side of perfect clarity.


>
> >>
> >> Some I have no idea about.
> >>
> >> + aes.c - absolutely no idea
> >> + rtl22xx/console/uart.c - maybe an x
> >> + powerpc/include/mpc83xx/mpc83xx.h - maybe an x
> >>
> >> I think a patch series doing copyright symbols, (r), and u for micro
> >> as individual changes would eliminate a lot and not be controversial.
> >> That should leave the remaining for a second pass.
> >>
> >> One patch per character change is safer to review.
> > "per kind of character"
> >
> > feel free to send all the (C) together, etc.
>
> OK.
>
> >
> > I think the AES one is pTq, math notation for a vector product using
> transpose.
> >
> > I used https://www.branah.com/unicode-converter and put the UTF-8 we
> > have in our repo in the box, and that gives some idea what it should
> > be in the top unicode box. i.e., put "¡°T¡±" in the UTF-8 box and see
> > what pops out on top
>
> That's a nice tool. Thanks for the hint.
>
> Best regards
>
> Christian
>
> >
> >>
> >> --joel
> >>
> >>
> >> On Thu, Nov 5, 2020 at 1:34 PM Christian Mauderer 
> wrote:
> >>>
> >>> Hello Joel,
> >>>
> >>> On 05/11/2020 20:15, Joel Sherrill wrote:
> 
> 
>  On Thu, Nov 5, 2020, 1:12 PM Christian Mauderer   > wrote:
> 
>  Hello Joel and Sebastian,
> 
>  On 05/11/2020 16:44, Joel Sherrill wrote:
>  >
>  >
>  > On Thu, Nov 5, 2020, 9:26 AM Sebastian Huber
>  >   
>  >   >> wrote:
>  >
>  > Hello,
>  >
>  > I review currently the Coding Conventions. Should the 80
>  characters
>  > limit be really a 79 characters limit with the \n as the
>  invisible 80th
>  > character?
>  >
>  >
>  > Yes.
>  >
>  > As old as this makes me feel, I remember printers which did an
>  automatic
>  > linefeed and then the newline one if you hit column 80. So it
>  really is
>  > 79 unfortunately.
> 
>  I don't think printers with an automatic linefeed are a common
> use case
>  for reading the RTEMS source code nowadays. So that maybe isn't
> the best
>  reason for using 79 characters.
> 
> 
>  +1
> 
> 
>  I would suggest to use the same convention that most coding
> styles use
>  which seems to be 80 characters:
> 
> 
> https://en.wikipedia.org/wiki/Characters_per_line#In_programming
> 
>  At least if there are no more recent examples for tools or
> editors where
>  79 is a benefit. 80 seems just feels a bit more natural.
> 
> 
>  By the way: If we count '\n': Should we count a tab '\t' as a
> single
>  character, as 2, as 4 or as 8 ones?
> 
> 
>  We shouldn't have tabs in code we own.
> >>>
> >>> Good point.
> >>>
> 
>  What about the few Unicode
>  characters that slipped in over the years?
> 
> 
>  We also shouldn't have unicode characters randomly floating around.
> T