Re: [PATCH 29/30] leon, greth: SMP support by using spin-lock protection

[Daniel Hellstrom]

On 2017-05-02 07:48, Sebastian Huber wrote:



On 13/04/17 21:31, Daniel Hellstrom wrote:

---
  c/src/lib/libbsp/sparc/shared/net/greth.c | 134 
--

  1 file changed, 71 insertions(+), 63 deletions(-)

diff --git a/c/src/lib/libbsp/sparc/shared/net/greth.c 
b/c/src/lib/libbsp/sparc/shared/net/greth.c

index 7726799..9af2de2 100644
--- a/c/src/lib/libbsp/sparc/shared/net/greth.c
+++ b/c/src/lib/libbsp/sparc/shared/net/greth.c
@@ -41,6 +41,18 @@
  #include 
  #include 
  +#include  /* spin-lock */
+
+/* map via ISR lock: */
+#define SPIN_DECLARE(lock) ISR_LOCK_MEMBER(lock)
+#define SPIN_INIT(lock, name) _ISR_lock_Initialize(lock, name)
+#define SPIN_LOCK(lock, level) _ISR_lock_Acquire_inline(lock, &level)
+#define SPIN_LOCK_IRQ(lock, level) 
_ISR_lock_ISR_disable_and_acquire(lock, &level)

+#define SPIN_UNLOCK(lock, level) _ISR_lock_Release_inline(lock, &level)
+#define SPIN_UNLOCK_IRQ(lock, level) 
_ISR_lock_Release_and_ISR_enable(lock, &level)

+#define SPIN_IRQFLAGS(k) ISR_lock_Context k
+#define SPIN_ISR_IRQFLAGS(k) SPIN_IRQFLAGS(k)


Could you please use the rtems_interrupt_lock_*() API and not the 
internal _ISR_lock_*() stuff.


Thanks. I think the reason for this may come from that the inline 
equivalent. I will add a patch which adds inline macros to the 
rtems_interrupt_lock interface instead. I can't see any reason why that 
can not be supported?


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

Re: [PATCH 29/30] leon, greth: SMP support by using spin-lock protection

[Sebastian Huber]

On 02/05/17 09:32, Daniel Hellstrom wrote:

On 2017-05-02 07:48, Sebastian Huber wrote:



On 13/04/17 21:31, Daniel Hellstrom wrote:

---
  c/src/lib/libbsp/sparc/shared/net/greth.c | 134 
--

  1 file changed, 71 insertions(+), 63 deletions(-)

diff --git a/c/src/lib/libbsp/sparc/shared/net/greth.c 
b/c/src/lib/libbsp/sparc/shared/net/greth.c

index 7726799..9af2de2 100644
--- a/c/src/lib/libbsp/sparc/shared/net/greth.c
+++ b/c/src/lib/libbsp/sparc/shared/net/greth.c
@@ -41,6 +41,18 @@
  #include 
  #include 
  +#include  /* spin-lock */
+
+/* map via ISR lock: */
+#define SPIN_DECLARE(lock) ISR_LOCK_MEMBER(lock)
+#define SPIN_INIT(lock, name) _ISR_lock_Initialize(lock, name)
+#define SPIN_LOCK(lock, level) _ISR_lock_Acquire_inline(lock, &level)
+#define SPIN_LOCK_IRQ(lock, level) 
_ISR_lock_ISR_disable_and_acquire(lock, &level)
+#define SPIN_UNLOCK(lock, level) _ISR_lock_Release_inline(lock, 
&level)
+#define SPIN_UNLOCK_IRQ(lock, level) 
_ISR_lock_Release_and_ISR_enable(lock, &level)

+#define SPIN_IRQFLAGS(k) ISR_lock_Context k
+#define SPIN_ISR_IRQFLAGS(k) SPIN_IRQFLAGS(k)


Could you please use the rtems_interrupt_lock_*() API and not the 
internal _ISR_lock_*() stuff.


Thanks. I think the reason for this may come from that the inline 
equivalent. I will add a patch which adds inline macros to the 
rtems_interrupt_lock interface instead. I can't see any reason why 
that can not be supported?


What do you mean with inline equivalent?

--
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail  : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.

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

Re: Warning Report on Master

[Daniel Hellstrom]

Hi Chris,

I started to look into the leon3 smp build recent problem and I think I 
located the problem with the version check. Since commit 
d420b679afc03f17d597193268e98966a0acd83d 2017-04-14 __RTEMS_REVISION__ 
was changed to __RTEMS_REVISION___ causing macros looking at 
__RTEMS_REVISION__ to fail because use of undefined macro name. I will 
add a patch to to my patch series and push it ASAP.


/Daniel

On 2017-05-01 00:36, Chris Johns wrote:

On 26/04/2017 09:18, Joel Sherrill wrote:


This is the latest warnings report for the master. This is
the first report in a LONG time where nearly all BSPs
were warning free.

Note that it ignores issues in code associated with the
old network stack. Now that the status is pretty good,
nibbling at those is a reasonable step.

ftp://ftp.rtems.org/pub/rtems/people/joel/warnings/warnings-4.12-master-20170425c 





I have attached a warnings report from the `rtems-bsp-builder` for 
tier-1 and a smp-debug build on Debian. There are 2 failures:


Failures:
   1 smp-debug i386/pc686  build:
  configure: /opt/work/chris/rtems/kernel/rtems.git/configure\
  --target=i386-rtems4.12 --enable-rtemsbsp=pc686\
  --prefix=/opt/rtems/4.12 --enable-debug --enable-smp 
--enable-tests\

  BSP_PRINT_EXCEPTION_CONTEXT=1
  error: pc686/lib/include/rtems/score/percpu.h:373:23 error: 
variable

  or field 'Interrupt_frame' declared void
   2 smp-debug sparc/leon3 build:
  configure: /opt/work/chris/rtems/kernel/rtems.git/configure 
--target\

  =sparc-rtems4.12 --enable-rtemsbsp=leon3 --prefix=/opt/rtems/4.12\
  --enable-debug --enable-smp --enable-tests
  error: c/src/lib/libbsp/sparc/shared/spw/grspw_pkt.c:61:2 error:
  #error SMP mode not compatible with these interrupt lock primitives

Chris


___
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 29/30] leon, greth: SMP support by using spin-lock protection

[Daniel Hellstrom]

On 2017-05-02 10:00, Sebastian Huber wrote:

On 02/05/17 09:32, Daniel Hellstrom wrote:

On 2017-05-02 07:48, Sebastian Huber wrote:



On 13/04/17 21:31, Daniel Hellstrom wrote:

---
  c/src/lib/libbsp/sparc/shared/net/greth.c | 134 
--

  1 file changed, 71 insertions(+), 63 deletions(-)

diff --git a/c/src/lib/libbsp/sparc/shared/net/greth.c 
b/c/src/lib/libbsp/sparc/shared/net/greth.c

index 7726799..9af2de2 100644
--- a/c/src/lib/libbsp/sparc/shared/net/greth.c
+++ b/c/src/lib/libbsp/sparc/shared/net/greth.c
@@ -41,6 +41,18 @@
  #include 
  #include 
  +#include  /* spin-lock */
+
+/* map via ISR lock: */
+#define SPIN_DECLARE(lock) ISR_LOCK_MEMBER(lock)
+#define SPIN_INIT(lock, name) _ISR_lock_Initialize(lock, name)
+#define SPIN_LOCK(lock, level) _ISR_lock_Acquire_inline(lock, &level)
+#define SPIN_LOCK_IRQ(lock, level) 
_ISR_lock_ISR_disable_and_acquire(lock, &level)
+#define SPIN_UNLOCK(lock, level) _ISR_lock_Release_inline(lock, 
&level)
+#define SPIN_UNLOCK_IRQ(lock, level) 
_ISR_lock_Release_and_ISR_enable(lock, &level)

+#define SPIN_IRQFLAGS(k) ISR_lock_Context k
+#define SPIN_ISR_IRQFLAGS(k) SPIN_IRQFLAGS(k)


Could you please use the rtems_interrupt_lock_*() API and not the 
internal _ISR_lock_*() stuff.


Thanks. I think the reason for this may come from that the inline 
equivalent. I will add a patch which adds inline macros to the 
rtems_interrupt_lock interface instead. I can't see any reason why 
that can not be supported?


What do you mean with inline equivalent?
I mean we use _ISR_lock_Acquire_inline(lock, &level) from the ISR to 
avoid an extra function call. But there is only a 
rtems_interrupt_lock_acquire_isr() no 
rtems_interrupt_lock_acquire_INLINE_isr() which we would like to use.


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

[PATCH] cpukit: Fix __RTEMS_REVISION__ define

[Sebastian Huber]

---
 cpukit/configure.ac|  2 +-
 testsuites/sptests/Makefile.am |  1 +
 testsuites/sptests/configure.ac|  1 +
 testsuites/sptests/spversion01/Makefile.am | 19 +
 testsuites/sptests/spversion01/init.c  | 53 ++
 testsuites/sptests/spversion01/spversion01.doc | 11 ++
 testsuites/sptests/spversion01/spversion01.scn |  2 +
 7 files changed, 88 insertions(+), 1 deletion(-)
 create mode 100644 testsuites/sptests/spversion01/Makefile.am
 create mode 100644 testsuites/sptests/spversion01/init.c
 create mode 100644 testsuites/sptests/spversion01/spversion01.doc
 create mode 100644 testsuites/sptests/spversion01/spversion01.scn

diff --git a/cpukit/configure.ac b/cpukit/configure.ac
index 67237e9..b0aa9a0 100644
--- a/cpukit/configure.ac
+++ b/cpukit/configure.ac
@@ -289,7 +289,7 @@ RTEMS_CPUOPT([__RTEMS_MINOR__],
   [$rtems_minor],
   [minor version portion of an RTEMS release])
 
-RTEMS_CPUOPT([__RTEMS_REVISION___],
+RTEMS_CPUOPT([__RTEMS_REVISION__],
   [true],
   [$rtems_revision],
   [revision version portion of an RTEMS release])
diff --git a/testsuites/sptests/Makefile.am b/testsuites/sptests/Makefile.am
index c50e757..d47bbca 100644
--- a/testsuites/sptests/Makefile.am
+++ b/testsuites/sptests/Makefile.am
@@ -33,6 +33,7 @@ _SUBDIRS = \
 spsignal_err01 spport_err01 spmsgq_err01 spmsgq_err02 spsem_err01 \
 spsem_err02 sptask_err01 spevent_err03 sptask_err03 sptask_err02 \
 sptask_err04 spclock_err01
+_SUBDIRS += spversion01
 _SUBDIRS += spfatal29
 _SUBDIRS += spmutex01
 _SUBDIRS += spextensions01
diff --git a/testsuites/sptests/configure.ac b/testsuites/sptests/configure.ac
index e14c937..a797d91 100644
--- a/testsuites/sptests/configure.ac
+++ b/testsuites/sptests/configure.ac
@@ -36,6 +36,7 @@ AM_CONDITIONAL(HAS_SMP,test "$rtems_cv_RTEMS_SMP" = "yes")
 
 # Explicitly list all Makefiles here
 AC_CONFIG_FILES([Makefile
+spversion01/Makefile
 spmutex01/Makefile
 spextensions01/Makefile
 sptimerserver01/Makefile
diff --git a/testsuites/sptests/spversion01/Makefile.am 
b/testsuites/sptests/spversion01/Makefile.am
new file mode 100644
index 000..73134d8
--- /dev/null
+++ b/testsuites/sptests/spversion01/Makefile.am
@@ -0,0 +1,19 @@
+rtems_tests_PROGRAMS = spversion01
+spversion01_SOURCES = init.c
+
+dist_rtems_tests_DATA = spversion01.scn spversion01.doc
+
+include $(RTEMS_ROOT)/make/custom/@RTEMS_BSP@.cfg
+include $(top_srcdir)/../automake/compile.am
+include $(top_srcdir)/../automake/leaf.am
+
+AM_CPPFLAGS += -I$(top_srcdir)/../support/include
+
+LINK_OBJS = $(spversion01_OBJECTS)
+LINK_LIBS = $(spversion01_LDLIBS)
+
+spversion01$(EXEEXT): $(spversion01_OBJECTS) $(spversion01_DEPENDENCIES)
+   @rm -f spversion01$(EXEEXT)
+   $(make-exe)
+
+include $(top_srcdir)/../automake/local.am
diff --git a/testsuites/sptests/spversion01/init.c 
b/testsuites/sptests/spversion01/init.c
new file mode 100644
index 000..f3ea708
--- /dev/null
+++ b/testsuites/sptests/spversion01/init.c
@@ -0,0 +1,53 @@
+/*
+ * Copyright (c) 2017 embedded brains GmbH.  All rights reserved.
+ *
+ *  embedded brains GmbH
+ *  Dornierstr. 4
+ *  82178 Puchheim
+ *  Germany
+ *  
+ *
+ * The license and distribution terms for this file may be
+ * found in the file LICENSE in this distribution or at
+ * http://www.rtems.org/license/LICENSE.
+ */
+
+#ifdef HAVE_CONFIG_H
+#include "config.h"
+#endif
+
+#include 
+
+#include "tmacros.h"
+
+const char rtems_test_name[] = "SPVERSION 1";
+
+static void test(void)
+{
+  rtems_test_assert(__RTEMS_MAJOR__ == 4);
+  rtems_test_assert(__RTEMS_MINOR__ == 11);
+  rtems_test_assert(__RTEMS_REVISION__ == 99);
+}
+
+static void Init(rtems_task_argument arg)
+{
+  TEST_BEGIN();
+
+  test();
+
+  TEST_END();
+  rtems_test_exit(0);
+}
+
+#define CONFIGURE_APPLICATION_DOES_NOT_NEED_CLOCK_DRIVER
+#define CONFIGURE_APPLICATION_NEEDS_CONSOLE_DRIVER
+
+#define CONFIGURE_MAXIMUM_TASKS 1
+
+#define CONFIGURE_INITIAL_EXTENSIONS RTEMS_TEST_INITIAL_EXTENSION
+
+#define CONFIGURE_RTEMS_INIT_TASKS_TABLE
+
+#define CONFIGURE_INIT
+
+#include 
diff --git a/testsuites/sptests/spversion01/spversion01.doc 
b/testsuites/sptests/spversion01/spversion01.doc
new file mode 100644
index 000..9a842f4
--- /dev/null
+++ b/testsuites/sptests/spversion01/spversion01.doc
@@ -0,0 +1,11 @@
+This file describes the directives and concepts tested by this test set.
+
+test set name: spversion01
+
+directives:
+
+  None.
+
+concepts:
+
+  Ensure that the RTEMS version macros are properly defined.
diff --git a/testsuites/sptests/spversion01/spversion01.scn 
b/testsuites/sptests/spversion01/spversion01.scn
new file mode 100644
index 000..735ed11
--- /dev/null
+++ b/testsuites/sptests/spversion01/spversion01.scn
@@ -0,0 +1,2 @@
+*** BEGIN OF TEST SPVERSION 1 ***
+*** END OF TEST SPVERSION 1 ***
-- 
1.8.4.5

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

Re: [PATCH 29/30] leon, greth: SMP support by using spin-lock protection

[Sebastian Huber]

On 02/05/17 10:16, Daniel Hellstrom wrote:

On 2017-05-02 10:00, Sebastian Huber wrote:

On 02/05/17 09:32, Daniel Hellstrom wrote:

On 2017-05-02 07:48, Sebastian Huber wrote:



On 13/04/17 21:31, Daniel Hellstrom wrote:

---
  c/src/lib/libbsp/sparc/shared/net/greth.c | 134 
--

  1 file changed, 71 insertions(+), 63 deletions(-)

diff --git a/c/src/lib/libbsp/sparc/shared/net/greth.c 
b/c/src/lib/libbsp/sparc/shared/net/greth.c

index 7726799..9af2de2 100644
--- a/c/src/lib/libbsp/sparc/shared/net/greth.c
+++ b/c/src/lib/libbsp/sparc/shared/net/greth.c
@@ -41,6 +41,18 @@
  #include 
  #include 
  +#include  /* spin-lock */
+
+/* map via ISR lock: */
+#define SPIN_DECLARE(lock) ISR_LOCK_MEMBER(lock)
+#define SPIN_INIT(lock, name) _ISR_lock_Initialize(lock, name)
+#define SPIN_LOCK(lock, level) _ISR_lock_Acquire_inline(lock, 
&level)
+#define SPIN_LOCK_IRQ(lock, level) 
_ISR_lock_ISR_disable_and_acquire(lock, &level)
+#define SPIN_UNLOCK(lock, level) _ISR_lock_Release_inline(lock, 
&level)
+#define SPIN_UNLOCK_IRQ(lock, level) 
_ISR_lock_Release_and_ISR_enable(lock, &level)

+#define SPIN_IRQFLAGS(k) ISR_lock_Context k
+#define SPIN_ISR_IRQFLAGS(k) SPIN_IRQFLAGS(k)


Could you please use the rtems_interrupt_lock_*() API and not the 
internal _ISR_lock_*() stuff.


Thanks. I think the reason for this may come from that the inline 
equivalent. I will add a patch which adds inline macros to the 
rtems_interrupt_lock interface instead. I can't see any reason why 
that can not be supported?


What do you mean with inline equivalent?
I mean we use _ISR_lock_Acquire_inline(lock, &level) from the ISR to 
avoid an extra function call. But there is only a 
rtems_interrupt_lock_acquire_isr() no 
rtems_interrupt_lock_acquire_INLINE_isr() which we would like to use.


Ok, but does this extra function call really matter? If you think so, 
then please add the *_inline variants to the rtems_interrupt_lock_* API 
(with tests) and document it in the user manual.


--
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail  : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.

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

Re: Warning Report on Master

[Sebastian Huber]

On 02/05/17 10:02, Daniel Hellstrom wrote:
I started to look into the leon3 smp build recent problem and I think 
I located the problem with the version check. Since commit 
d420b679afc03f17d597193268e98966a0acd83d 2017-04-14 __RTEMS_REVISION__ 
was changed to __RTEMS_REVISION___ causing macros looking at 
__RTEMS_REVISION__ to fail because use of undefined macro name. I will 
add a patch to to my patch series and push it ASAP.


Please have a look at this patch:

https://lists.rtems.org/pipermail/devel/2017-May/017687.html

--
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail  : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.

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

Re: [PATCH 23/30] leon, ahbstat: Use RTEMS 4.12 SMP interrupt lock

[Sebastian Huber]

On 13/04/17 21:31, Daniel Hellstrom wrote:

#include 


Please don't include internal header files, use  instead.

--
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail  : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.

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

Re: [PATCH] cpukit: Fix __RTEMS_REVISION__ define

[Daniel Hellstrom]

Ok, good. I just was about to send my patch, but now I wont. Thanks!

On 2017-05-02 10:20, Sebastian Huber wrote:

---
  cpukit/configure.ac|  2 +-
  testsuites/sptests/Makefile.am |  1 +
  testsuites/sptests/configure.ac|  1 +
  testsuites/sptests/spversion01/Makefile.am | 19 +
  testsuites/sptests/spversion01/init.c  | 53 ++
  testsuites/sptests/spversion01/spversion01.doc | 11 ++
  testsuites/sptests/spversion01/spversion01.scn |  2 +
  7 files changed, 88 insertions(+), 1 deletion(-)
  create mode 100644 testsuites/sptests/spversion01/Makefile.am
  create mode 100644 testsuites/sptests/spversion01/init.c
  create mode 100644 testsuites/sptests/spversion01/spversion01.doc
  create mode 100644 testsuites/sptests/spversion01/spversion01.scn

diff --git a/cpukit/configure.ac b/cpukit/configure.ac
index 67237e9..b0aa9a0 100644
--- a/cpukit/configure.ac
+++ b/cpukit/configure.ac
@@ -289,7 +289,7 @@ RTEMS_CPUOPT([__RTEMS_MINOR__],
[$rtems_minor],
[minor version portion of an RTEMS release])
  
-RTEMS_CPUOPT([__RTEMS_REVISION___],

+RTEMS_CPUOPT([__RTEMS_REVISION__],
[true],
[$rtems_revision],
[revision version portion of an RTEMS release])
diff --git a/testsuites/sptests/Makefile.am b/testsuites/sptests/Makefile.am
index c50e757..d47bbca 100644
--- a/testsuites/sptests/Makefile.am
+++ b/testsuites/sptests/Makefile.am
@@ -33,6 +33,7 @@ _SUBDIRS = \
  spsignal_err01 spport_err01 spmsgq_err01 spmsgq_err02 spsem_err01 \
  spsem_err02 sptask_err01 spevent_err03 sptask_err03 sptask_err02 \
  sptask_err04 spclock_err01
+_SUBDIRS += spversion01
  _SUBDIRS += spfatal29
  _SUBDIRS += spmutex01
  _SUBDIRS += spextensions01
diff --git a/testsuites/sptests/configure.ac b/testsuites/sptests/configure.ac
index e14c937..a797d91 100644
--- a/testsuites/sptests/configure.ac
+++ b/testsuites/sptests/configure.ac
@@ -36,6 +36,7 @@ AM_CONDITIONAL(HAS_SMP,test "$rtems_cv_RTEMS_SMP" = "yes")
  
  # Explicitly list all Makefiles here

  AC_CONFIG_FILES([Makefile
+spversion01/Makefile
  spmutex01/Makefile
  spextensions01/Makefile
  sptimerserver01/Makefile
diff --git a/testsuites/sptests/spversion01/Makefile.am 
b/testsuites/sptests/spversion01/Makefile.am
new file mode 100644
index 000..73134d8
--- /dev/null
+++ b/testsuites/sptests/spversion01/Makefile.am
@@ -0,0 +1,19 @@
+rtems_tests_PROGRAMS = spversion01
+spversion01_SOURCES = init.c
+
+dist_rtems_tests_DATA = spversion01.scn spversion01.doc
+
+include $(RTEMS_ROOT)/make/custom/@RTEMS_BSP@.cfg
+include $(top_srcdir)/../automake/compile.am
+include $(top_srcdir)/../automake/leaf.am
+
+AM_CPPFLAGS += -I$(top_srcdir)/../support/include
+
+LINK_OBJS = $(spversion01_OBJECTS)
+LINK_LIBS = $(spversion01_LDLIBS)
+
+spversion01$(EXEEXT): $(spversion01_OBJECTS) $(spversion01_DEPENDENCIES)
+   @rm -f spversion01$(EXEEXT)
+   $(make-exe)
+
+include $(top_srcdir)/../automake/local.am
diff --git a/testsuites/sptests/spversion01/init.c 
b/testsuites/sptests/spversion01/init.c
new file mode 100644
index 000..f3ea708
--- /dev/null
+++ b/testsuites/sptests/spversion01/init.c
@@ -0,0 +1,53 @@
+/*
+ * Copyright (c) 2017 embedded brains GmbH.  All rights reserved.
+ *
+ *  embedded brains GmbH
+ *  Dornierstr. 4
+ *  82178 Puchheim
+ *  Germany
+ *  
+ *
+ * The license and distribution terms for this file may be
+ * found in the file LICENSE in this distribution or at
+ * http://www.rtems.org/license/LICENSE.
+ */
+
+#ifdef HAVE_CONFIG_H
+#include "config.h"
+#endif
+
+#include 
+
+#include "tmacros.h"
+
+const char rtems_test_name[] = "SPVERSION 1";
+
+static void test(void)
+{
+  rtems_test_assert(__RTEMS_MAJOR__ == 4);
+  rtems_test_assert(__RTEMS_MINOR__ == 11);
+  rtems_test_assert(__RTEMS_REVISION__ == 99);
+}
+
+static void Init(rtems_task_argument arg)
+{
+  TEST_BEGIN();
+
+  test();
+
+  TEST_END();
+  rtems_test_exit(0);
+}
+
+#define CONFIGURE_APPLICATION_DOES_NOT_NEED_CLOCK_DRIVER
+#define CONFIGURE_APPLICATION_NEEDS_CONSOLE_DRIVER
+
+#define CONFIGURE_MAXIMUM_TASKS 1
+
+#define CONFIGURE_INITIAL_EXTENSIONS RTEMS_TEST_INITIAL_EXTENSION
+
+#define CONFIGURE_RTEMS_INIT_TASKS_TABLE
+
+#define CONFIGURE_INIT
+
+#include 
diff --git a/testsuites/sptests/spversion01/spversion01.doc 
b/testsuites/sptests/spversion01/spversion01.doc
new file mode 100644
index 000..9a842f4
--- /dev/null
+++ b/testsuites/sptests/spversion01/spversion01.doc
@@ -0,0 +1,11 @@
+This file describes the directives and concepts tested by this test set.
+
+test set name: spversion01
+
+directives:
+
+  None.
+
+concepts:
+
+  Ensure that the RTEMS version macros are properly defined.
diff --git a/testsuites/sptests/spversion01/spversion01.scn 
b/testsuites/sptests/spversion01/spversion01.scn
new file mode 100644
index 000..735ed11
--- /dev/null
+++ b/testsuites/sptests/spversion01/spversion01.scn
@@ -0,0 +1,2 @@
+*** BEGIN OF TEST SPVERSION 1 ***
+*** END O

Re: [PATCH 29/30] leon, greth: SMP support by using spin-lock protection

[Daniel Hellstrom]

On 2017-05-02 10:27, Sebastian Huber wrote:



On 02/05/17 10:16, Daniel Hellstrom wrote:

On 2017-05-02 10:00, Sebastian Huber wrote:

On 02/05/17 09:32, Daniel Hellstrom wrote:

On 2017-05-02 07:48, Sebastian Huber wrote:



On 13/04/17 21:31, Daniel Hellstrom wrote:

---
  c/src/lib/libbsp/sparc/shared/net/greth.c | 134 
--

  1 file changed, 71 insertions(+), 63 deletions(-)

diff --git a/c/src/lib/libbsp/sparc/shared/net/greth.c 
b/c/src/lib/libbsp/sparc/shared/net/greth.c

index 7726799..9af2de2 100644
--- a/c/src/lib/libbsp/sparc/shared/net/greth.c
+++ b/c/src/lib/libbsp/sparc/shared/net/greth.c
@@ -41,6 +41,18 @@
  #include 
  #include 
  +#include  /* spin-lock */
+
+/* map via ISR lock: */
+#define SPIN_DECLARE(lock) ISR_LOCK_MEMBER(lock)
+#define SPIN_INIT(lock, name) _ISR_lock_Initialize(lock, name)
+#define SPIN_LOCK(lock, level) _ISR_lock_Acquire_inline(lock, 
&level)
+#define SPIN_LOCK_IRQ(lock, level) 
_ISR_lock_ISR_disable_and_acquire(lock, &level)
+#define SPIN_UNLOCK(lock, level) _ISR_lock_Release_inline(lock, 
&level)
+#define SPIN_UNLOCK_IRQ(lock, level) 
_ISR_lock_Release_and_ISR_enable(lock, &level)

+#define SPIN_IRQFLAGS(k) ISR_lock_Context k
+#define SPIN_ISR_IRQFLAGS(k) SPIN_IRQFLAGS(k)


Could you please use the rtems_interrupt_lock_*() API and not the 
internal _ISR_lock_*() stuff.


Thanks. I think the reason for this may come from that the inline 
equivalent. I will add a patch which adds inline macros to the 
rtems_interrupt_lock interface instead. I can't see any reason why 
that can not be supported?


What do you mean with inline equivalent?
I mean we use _ISR_lock_Acquire_inline(lock, &level) from the ISR to 
avoid an extra function call. But there is only a 
rtems_interrupt_lock_acquire_isr() no 
rtems_interrupt_lock_acquire_INLINE_isr() which we would like to use.


Ok, but does this extra function call really matter? If you think so, 
then please add the *_inline variants to the rtems_interrupt_lock_* 
API (with tests) and document it in the user manual.
Ok. I will add that patch afterwards, first I will fix our patches to 
use the correct existing macros. On SPARC it would be nice to avoid the 
extra window SAVE within the ISR.


Daniel

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

Re: [PATCH 29/30] leon, greth: SMP support by using spin-lock protection

[Sebastian Huber]

On 02/05/17 10:51, Daniel Hellstrom wrote:


On 2017-05-02 10:27, Sebastian Huber wrote:



On 02/05/17 10:16, Daniel Hellstrom wrote:

On 2017-05-02 10:00, Sebastian Huber wrote:

On 02/05/17 09:32, Daniel Hellstrom wrote:

On 2017-05-02 07:48, Sebastian Huber wrote:



On 13/04/17 21:31, Daniel Hellstrom wrote:

---
  c/src/lib/libbsp/sparc/shared/net/greth.c | 134 
--

  1 file changed, 71 insertions(+), 63 deletions(-)

diff --git a/c/src/lib/libbsp/sparc/shared/net/greth.c 
b/c/src/lib/libbsp/sparc/shared/net/greth.c

index 7726799..9af2de2 100644
--- a/c/src/lib/libbsp/sparc/shared/net/greth.c
+++ b/c/src/lib/libbsp/sparc/shared/net/greth.c
@@ -41,6 +41,18 @@
  #include 
  #include 
  +#include  /* spin-lock */
+
+/* map via ISR lock: */
+#define SPIN_DECLARE(lock) ISR_LOCK_MEMBER(lock)
+#define SPIN_INIT(lock, name) _ISR_lock_Initialize(lock, name)
+#define SPIN_LOCK(lock, level) _ISR_lock_Acquire_inline(lock, 
&level)
+#define SPIN_LOCK_IRQ(lock, level) 
_ISR_lock_ISR_disable_and_acquire(lock, &level)
+#define SPIN_UNLOCK(lock, level) _ISR_lock_Release_inline(lock, 
&level)
+#define SPIN_UNLOCK_IRQ(lock, level) 
_ISR_lock_Release_and_ISR_enable(lock, &level)

+#define SPIN_IRQFLAGS(k) ISR_lock_Context k
+#define SPIN_ISR_IRQFLAGS(k) SPIN_IRQFLAGS(k)


Could you please use the rtems_interrupt_lock_*() API and not the 
internal _ISR_lock_*() stuff.


Thanks. I think the reason for this may come from that the inline 
equivalent. I will add a patch which adds inline macros to the 
rtems_interrupt_lock interface instead. I can't see any reason why 
that can not be supported?


What do you mean with inline equivalent?
I mean we use _ISR_lock_Acquire_inline(lock, &level) from the ISR to 
avoid an extra function call. But there is only a 
rtems_interrupt_lock_acquire_isr() no 
rtems_interrupt_lock_acquire_INLINE_isr() which we would like to use.


Ok, but does this extra function call really matter? If you think so, 
then please add the *_inline variants to the rtems_interrupt_lock_* 
API (with tests) and document it in the user manual.
Ok. I will add that patch afterwards, first I will fix our patches to 
use the correct existing macros. 


Ok. You can commit the patch set from my point of view (with the minor 
fixes).



On SPARC it would be nice to avoid the extra window SAVE within the ISR.


Since, greth_interrupt() conditionally calls rtems_bsdnet_event_send() 
the greth_interrupt() already uses a SAVE, the SMP lock acquire is a 
tail function.


--
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail  : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.

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

Re: [PATCH 29/30] leon, greth: SMP support by using spin-lock protection

[Daniel Hellstrom]

On 2017-05-02 11:00, Sebastian Huber wrote:



On 02/05/17 10:51, Daniel Hellstrom wrote:


On 2017-05-02 10:27, Sebastian Huber wrote:



On 02/05/17 10:16, Daniel Hellstrom wrote:

On 2017-05-02 10:00, Sebastian Huber wrote:

On 02/05/17 09:32, Daniel Hellstrom wrote:

On 2017-05-02 07:48, Sebastian Huber wrote:



On 13/04/17 21:31, Daniel Hellstrom wrote:

---
  c/src/lib/libbsp/sparc/shared/net/greth.c | 134 
--

  1 file changed, 71 insertions(+), 63 deletions(-)

diff --git a/c/src/lib/libbsp/sparc/shared/net/greth.c 
b/c/src/lib/libbsp/sparc/shared/net/greth.c

index 7726799..9af2de2 100644
--- a/c/src/lib/libbsp/sparc/shared/net/greth.c
+++ b/c/src/lib/libbsp/sparc/shared/net/greth.c
@@ -41,6 +41,18 @@
  #include 
  #include 
  +#include  /* spin-lock */
+
+/* map via ISR lock: */
+#define SPIN_DECLARE(lock) ISR_LOCK_MEMBER(lock)
+#define SPIN_INIT(lock, name) _ISR_lock_Initialize(lock, name)
+#define SPIN_LOCK(lock, level) _ISR_lock_Acquire_inline(lock, 
&level)
+#define SPIN_LOCK_IRQ(lock, level) 
_ISR_lock_ISR_disable_and_acquire(lock, &level)
+#define SPIN_UNLOCK(lock, level) 
_ISR_lock_Release_inline(lock, &level)
+#define SPIN_UNLOCK_IRQ(lock, level) 
_ISR_lock_Release_and_ISR_enable(lock, &level)

+#define SPIN_IRQFLAGS(k) ISR_lock_Context k
+#define SPIN_ISR_IRQFLAGS(k) SPIN_IRQFLAGS(k)


Could you please use the rtems_interrupt_lock_*() API and not 
the internal _ISR_lock_*() stuff.


Thanks. I think the reason for this may come from that the inline 
equivalent. I will add a patch which adds inline macros to the 
rtems_interrupt_lock interface instead. I can't see any reason 
why that can not be supported?


What do you mean with inline equivalent?
I mean we use _ISR_lock_Acquire_inline(lock, &level) from the ISR 
to avoid an extra function call. But there is only a 
rtems_interrupt_lock_acquire_isr() no 
rtems_interrupt_lock_acquire_INLINE_isr() which we would like to use.


Ok, but does this extra function call really matter? If you think 
so, then please add the *_inline variants to the 
rtems_interrupt_lock_* API (with tests) and document it in the user 
manual.
Ok. I will add that patch afterwards, first I will fix our patches to 
use the correct existing macros. 


Ok. You can commit the patch set from my point of view (with the minor 
fixes).


good, thanks for the review.




On SPARC it would be nice to avoid the extra window SAVE within the ISR.


Since, greth_interrupt() conditionally calls rtems_bsdnet_event_send() 
the greth_interrupt() already uses a SAVE, the SMP lock acquire is a 
tail function.


I agree, I hope to use the macros in several ISRs in some it might not 
have an effect in others it may.


/Daniel

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

GCC 7.1 Released

[Joel Sherrill]

Hi

Thoughts on upgrading the 4.12 tools?

--joel


 Forwarded Message 
Subject: GCC 7.1 Released
Date: Tue, 2 May 2017 10:57:28 -0500
From: Jakub Jelinek 
Reply-To: Jakub Jelinek 
To: g...@gcc.gnu.org 

We are proud to announce the next, major release of the
GNU Compiler Collection, 7.1.  This year we celebrated the 30th
anniversary of the first GCC beta release and this month
we will celebrate 30 years since the GCC 1.0 release.

GCC 7.1 is a major release containing substantial new
functionality not available in GCC 6.x or previous GCC releases.

The C++ frontend now has experimental support for all of the current C++17
draft, with the -std=c++1z and -std=gnu++1z options, and the libstdc++
library has most of the C++17 draft library features implemented too.

This releases features various improvements in the emitted diagnostics,
including improved locations, location ranges, suggestions for misspelled
identifiers, option names, fix-it hints and various new warnings
have been added.

The optimizers have been improved, with improvements appearing in all of
intra- and inter-procedural optimizations, link time optimizations and
various target backends, including, but not limited to, additions of store
merging pass, code hoisting optimization, loop splitting, and
shrink wrapping improvements.

The Address Sanitizer can now report uses of variables after leaving their
scope.  GCC now can be configured for OpenMP 4.5 offloading to NVidia PTX
GPGPUs.

Some code that compiled successfully with older GCC versions might require
some code adjustments, see http://gcc.gnu.org/gcc-7/porting_to.html for
details.

See

  https://gcc.gnu.org/gcc-7/changes.html

for more information about changes in GCC 7.1.

This release is available from the FTP servers listed here:

 http://www.gnu.org/order/ftp.html

The release is in gcc/gcc-7.1.0/ subdirectory.

If you encounter difficulties using GCC 7.1, please do not contact me
directly.  Instead, please visit http://gcc.gnu.org for information
about getting help.

Driving a leading free software project such as GNU Compiler Collection
would not be possible without support from its many contributors.
Not to only mention its developers but especially its regular testers
and users which contribute to its high quality.  The list of individuals
is too large to thank individually!

Please consider a donation to the GNU Toolchain Fund to support the
continued development of GCC!
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] cpukit: Fix __RTEMS_REVISION__ define

[Chris Johns]

On 2/5/17 6:20 pm, Sebastian Huber wrote:
> +  rtems_test_assert(__RTEMS_MAJOR__ == 4);
> +  rtems_test_assert(__RTEMS_MINOR__ == 11);
> +  rtems_test_assert(__RTEMS_REVISION__ == 99);

Please do not push this test like this, it breaks releases. The test
will never pass on a release.

If you want to add this test please extract the version details from the
build system and pass into the compiler the values and compare them.

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

Re: GCC 7.1 Released

[Chris Johns]

On 3/5/17 3:04 am, Joel Sherrill wrote:
> 
> Thoughts on upgrading the 4.12 tools?
> 

Looks good with updated dependent packages for gcc and with
binutils-2.28. There are no build failures for just the tests. Attached
is the warnings report which looks good if the networking warnings are
ignored.

The test results for erc32 are:

Passed:548
Failed:  2
User Input:  4
Expected Fail:   0
Indeterminate:   0
Benchmark:   3
Timeout: 1
Invalid: 1
--
Total: 559

Failures:
 tar01.exe
 spcontext01.exe
User Input:
 fileio.exe
 top.exe
 termios.exe
 monitor.exe
Benchmark:
 dhrystone.exe
 whetstone.exe
 linpack.exe
Timeouts:
 capture.exe
Invalid:
 minimum.exe

I think capture needs to be tagged as user input.

Chris
RTEMS Tools Project - RTEMS Kernel BSP Builder, 4.12.not_released

Date: Wed May  3 21:04:05 2017

command: /opt/work/rtems/4.12/bin/rtems-bsp-builder --rtems-\
 tools=/build/rtems/tools/4.12\
 --rtems=/opt/work/chris/rtems/kernel/rtems.git --build=tests\
 --log=x --warnings-report=warnings-tier-1-tests.txt

 +=+
 | By Architecture (total : 288)   |
 +-+
 | common : 33 warning(s)  |
 +-+++-+
 |   Shared :0 | BSP :0 | Network :  136 |Tests :0 |
 |   LibCPU :0 | CPU Kit :0 || |
 +---+-+++-+
 | 4 | cpukit/librpc/src/rpc/get_myaddress.c:130:5 |
 | 2 | cpukit/libnetworking/libc/getservbyport.c:52:4  |
 | 2 | cpukit/libnetworking/netinet/tcp_usrreq.c:106:16|
 | 2 | cpukit/librpc/src/rpc/rpc_dtablesize.c:55:1 |
 | 2 | cpukit/libnetworking/libc/getservbyname.c:52:4  |
 | 2 | cpukit/librpc/src/rpc/rpc_prot.c:215:2  |
 | 2 | cpukit/librpc/src/rpc/get_myaddress.c:80:1  |
 | 2 | cpukit/librpc/src/rpc/rpc_prot.c:255:2  |
 | 2 | cpukit/librpc/src/rpc/rpcdname.c:78:1   |
 | 2 | cpukit/libnetworking/libc/res_update.c:90:12|
 | 2 | cpukit/libnetworking/netinet/tcp_output.c:408:4 |
 | 2 | cpukit/libnetworking/netinet/tcp_output.c:422:5 |
 | 2 | cpukit/librpc/src/rpc/getrpcport.c:52:1 |
 | 2 | cpukit/libnetworking/netinet/tcp_usrreq.c:497:16|
 | 2 | cpukit/libnetworking/lib/getprotoby.c:37:1  |
 | 2 | cpukit/librpc/src/rpc/rpc_prot.c:115:2  |
 | 2 | cpukit/librpc/src/rpc/auth_unix.c:102:1 |
 | 2 | cpukit/libnetworking/netinet/tcp_output.c:393:4 |
 | 2 | cpukit/libnetworking/lib/getprotoby.c:22:1  |
 | 2 | cpukit/librpc/src/rpc/svc_simple.c:71:1 |
 | 2 | cpukit/libnetworking/netinet/tcp_output.c:429:5 |
 | 2 | cpukit/libnetworking/netinet/tcp_usrreq.c:182:16|
 | 2 | cpukit/librpc/src/rpc/clnt_simple.c:65:1|
 | 2 | cpukit/librpc/src/rpc/rpc_prot.c:138:1  |
 | 2 | cpukit/librpc/src/rpc/rpc_prot.c:105:1  |
 | 2 | cpukit/librpc/src/rpc/svc_udp.c:346:5   |
 | 2 | cpukit/librpc/src/rpc/svc_auth_unix.c:147:1 |
 | 2 | cpukit/librpc/src/rpc/svc_auth_unix.c:59:1  |
 | 2 | cpukit/libnetworking/netinet/tcp_usrreq.c:292:16|
 | 2 | cpukit/libnetworking/libc/gethostnamadr.c:169:4 |
 | 2 | cpukit/librpc/src/rpc/rtime.c:75:1  |
 | 2 | cpukit/libnetworking/netinet/tcp_usrreq.c:484:16|
 | 2 | cpukit/librpc/src/rpc/rpc_prot.c:146:2  |
 +---+-+
 | arm : 1 warning(s)  |
 +-+++-+
 |   Shared :0 | BSP :0 | Network :  175 |Tests :0 |
 |   LibCPU :0 | CPU Kit :0 || |
 +---+-+++-+
 | 5 | cpukit/libnetworking/netinet/in_cksum.c:84:1|
 +---+-+
 | i386 : 1 warning(s) |
 +-+++-+
 |   Shared :0 | BSP :0 | Network :   35 |Tests :0 |
 |   LibCPU :0 | CPU Kit :0 || |
 +---+

Re: [PATCH] cpukit: Fix __RTEMS_REVISION__ define

[Sebastian Huber]

On 02/05/17 23:30, Chris Johns wrote:

On 2/5/17 6:20 pm, Sebastian Huber wrote:

+  rtems_test_assert(__RTEMS_MAJOR__ == 4);
+  rtems_test_assert(__RTEMS_MINOR__ == 11);
+  rtems_test_assert(__RTEMS_REVISION__ == 99);

Please do not push this test like this, it breaks releases. The test
will never pass on a release.


In case someone adjusts the version number, this test must be adjusted 
accordingly. Where do I find the right document to mention this?




If you want to add this test please extract the version details from the
build system


Can we trust the build system?

--
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail  : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.

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

Re: GCC 7.1 Released

[Sebastian Huber]

On 03/05/17 03:33, Chris Johns wrote:

On 3/5/17 3:04 am, Joel Sherrill wrote:

>
>Thoughts on upgrading the 4.12 tools?
>

Looks good with updated dependent packages for gcc and with
binutils-2.28. There are no build failures for just the tests. Attached
is the warnings report which looks good if the networking warnings are
ignored.


I would rather use the GCC 6 which received some bug fix releases in the 
mean time and was used most of the time of the RTEMS 4.12 development. 
For RTEMS 5 I would use GCC 8.


--
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail  : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.

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

Re: [PATCH] cpukit: Fix __RTEMS_REVISION__ define

[Chris Johns]

On 3/5/17 3:09 pm, Sebastian Huber wrote:
> On 02/05/17 23:30, Chris Johns wrote:
>> On 2/5/17 6:20 pm, Sebastian Huber wrote:
>>> +  rtems_test_assert(__RTEMS_MAJOR__ == 4);
>>> +  rtems_test_assert(__RTEMS_MINOR__ == 11);
>>> +  rtems_test_assert(__RTEMS_REVISION__ == 99);
>> Please do not push this test like this, it breaks releases. The test
>> will never pass on a release.
> 
> In case someone adjusts the version number, this test must be adjusted
> accordingly.

As I said please do not push this test like this. Releasing does not
work this way. It breaks the releases and if pushed it will become a
release blocker.

> Where do I find the right document to mention this?

If you are asking where to document updating this test please do not
bother. This type of data should not exist in sources that need to be
committed and pushed. It can exist in the current build system files
(version.m4) and any generated files packaged in to a release. As a
result I do not accept this test as it stands for RTEMS.

I am happy to see something that clearly states there is to be no
numbering related to the "current" version numbering to be placed in
source files. The version can exist in the current list of version.m4
files and these can be used to create suitable compiler command line
defines. Maybe this needs to be added to the coding standard.

>>
>> If you want to add this test please extract the version details from the
>> build system
> 
> Can we trust the build system?
> 

Given the header file with the values it created by the build system yes
we can.

I assume the test is checking the build system is correctly creating the
header file. Maybe it should check the values are only numbers.

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

Re: [PATCH] cpukit: Fix __RTEMS_REVISION__ define

[Sebastian Huber]

On 03/05/17 07:28, Chris Johns wrote:

On 3/5/17 3:09 pm, Sebastian Huber wrote:

On 02/05/17 23:30, Chris Johns wrote:

On 2/5/17 6:20 pm, Sebastian Huber wrote:
[...]



If you want to add this test please extract the version details from the
build system

Can we trust the build system?


Given the header file with the values it created by the build system yes
we can.


I don't think we can trust the build system. The requirement for a 
release is that the version macros should have specific values. We 
should test that this is the case.


Maybe we have some time in the future something like this:

Requirement 2341: There shall be a C pre-processor define 
__RTEMS_MAJOR__ available via #include  defined to 123.


--
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail  : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.

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

Re: [PATCH] cpukit: Fix __RTEMS_REVISION__ define

[Chris Johns]

On 3/5/17 3:40 pm, Sebastian Huber wrote:
> 
> On 03/05/17 07:28, Chris Johns wrote:
>> On 3/5/17 3:09 pm, Sebastian Huber wrote:
>>> On 02/05/17 23:30, Chris Johns wrote:
 On 2/5/17 6:20 pm, Sebastian Huber wrote:
 [...]
> 
 If you want to add this test please extract the version details from
 the
 build system
>>> Can we trust the build system?
>>>
>> Given the header file with the values it created by the build system yes
>> we can.
> 
> I don't think we can trust the build system. The requirement for a
> release is that the version macros should have specific values. We
> should test that this is the case.

We have to trust the build system for a clean or fresh build and if we
cannot not it is a bug. To state otherwise expands the scope of
uncertainty and I do not believe we need too.

I will state again, doing this breaks the release process. I am sorry
but this is just now the release model and supporting configuration
control structures exist.

> 
> Maybe we have some time in the future something like this:
> 
> Requirement 2341: There shall be a C pre-processor define
> __RTEMS_MAJOR__ available via #include  defined to 123.

I doubt this would be in the RTEMS Project's requirements. It might be
in a qualification package for the specific qualification effort. How
that define it created is for the RTEMS Project to determine.

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

Re: [PATCH] cpukit: Fix __RTEMS_REVISION__ define

[Sebastian Huber]

On 03/05/17 08:17, Chris Johns wrote:

On 3/5/17 3:40 pm, Sebastian Huber wrote:

On 03/05/17 07:28, Chris Johns wrote:

On 3/5/17 3:09 pm, Sebastian Huber wrote:

On 02/05/17 23:30, Chris Johns wrote:

On 2/5/17 6:20 pm, Sebastian Huber wrote:
[...]
If you want to add this test please extract the version details from
the
build system

Can we trust the build system?


Given the header file with the values it created by the build system yes
we can.

I don't think we can trust the build system. The requirement for a
release is that the version macros should have specific values. We
should test that this is the case.

We have to trust the build system for a clean or fresh build and if we
cannot not it is a bug. To state otherwise expands the scope of
uncertainty and I do not believe we need too.

I will state again, doing this breaks the release process. I am sorry
but this is just now the release model and supporting configuration
control structures exist.


I still don't see how this breaks the release process. One task of it is 
surly to change the version from N to N + 1. This requires to modify 
some files (with a script). This test would be just one of these files. 
Some are *.m4 files, some *.c files, it doesn't matter.





Maybe we have some time in the future something like this:

Requirement 2341: There shall be a C pre-processor define
__RTEMS_MAJOR__ available via #include  defined to 123.

I doubt this would be in the RTEMS Project's requirements. It might be
in a qualification package for the specific qualification effort.


It is a RTEMS Project's requirement. Its just not explicitly stated. If 
you release RTEMS 3.4.531 a user expects to have


#define __RTEMS_MAJOR__ 3
#define __RTEMS_MINOR__ 4
#define __RTEMS_REVISION__ 531


How
that define it created is for the RTEMS Project to determine.


Yes, but somehow the define must exist with the right value and this is 
what needs to be tested.


--
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail  : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.

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