Re: [PATCH] ci: Tune config

2019-04-10 Thread Roman Stratiienko via Xenomai
I did measurements after clearing cache 'ccache -C'

I assume that 600mb in current statistic is due to multiple build of
different source dependencies due to enabled DEBUG INFO config. Old cache
should be invalidated and cleaned automatically as size goes up to the
limit.


ср, 10 апр. 2019 г., 08:34 Jan Kiszka :

> On 09.04.19 22:47, Roman Stratiienko wrote:
> >
> > I have similar issue some time ago on another project, but due to lack
> of time
> > and low priority it was unsolved.
> > And you've found the root cause and it is great, thanks!.
>
> At least it looks like as the rebuild no only takes 15 minutes.
>
> >
> > I did some measurements of ccache size, and results is following:
> > - 4.14 arm64 - cache size - 232.7 MB
> > - 4.19 arm - cache size - 246.4 MB
> > - Others are even less.
> >
> > So I suggest to left it 400MB, thus not to use too much disk space of
> travis's
> > servers.
>
> Look at the statistics you added to our build:
>
> 4.14 arm64: 601.6 MB
> 4.19 arm:   557.7 MB
> 4.14 x86:   292.5 MB
>
> If you cap the size, ccache may drop artifacts during the build, then
> refill,
> but may stay below the limit at the end. Still, the cache will be
> incomplete.
>
> Jan
>
> --
> Siemens AG, Corporate Technology, CT RDA IOT SES-DE
> Corporate Competence Center Embedded Linux
>


[PATCH v3 3/5] libcobalt: improve condvar autoinit support

2019-04-10 Thread Norbert Lange via Xenomai
contrary to some comments, condvars are automatically
initialised on signal/wait.
Correct the destroy method to not report an
error on such condvars.

Check whether the condition variable has the
static initializer is now more strict.

Signed-off-by: Norbert Lange 
---
 lib/cobalt/cond.c | 86 +++
 1 file changed, 43 insertions(+), 43 deletions(-)

diff --git a/lib/cobalt/cond.c b/lib/cobalt/cond.c
index 00a201855..9553824c2 100644
--- a/lib/cobalt/cond.c
+++ b/lib/cobalt/cond.c
@@ -142,6 +142,32 @@ COBALT_IMPL(int, pthread_cond_init, (pthread_cond_t *cond,
return 0;
 }
 
+static int __attribute__((cold))
+   cobalt_cond_autoinit_type(const pthread_cond_t *cond)
+{
+   static const pthread_cond_t cond_initializer =
+   PTHREAD_COND_INITIALIZER;
+
+   return memcmp(cond, &cond_initializer, sizeof(cond_initializer)) == 0 ?
+   0 : -1;
+}
+
+static int __attribute__((cold))
+   cobalt_cond_doautoinit(union cobalt_cond_union *ucond)
+{
+   if (cobalt_cond_autoinit_type(&ucond->native_cond) < 0)
+   return EINVAL;
+
+   return __COBALT(pthread_cond_init(&ucond->native_cond, NULL));
+}
+
+static inline int cobalt_cond_autoinit(union cobalt_cond_union *ucond)
+{
+   if (unlikely(ucond->shadow_cond.magic != COBALT_COND_MAGIC))
+   return cobalt_cond_doautoinit(ucond);
+   return 0;
+}
+
 /**
  * @fn int pthread_cond_destroy(pthread_cond_t *cond)
  * @brief Destroy a condition variable
@@ -168,7 +194,11 @@ COBALT_IMPL(int, pthread_cond_init, (pthread_cond_t *cond,
  */
 COBALT_IMPL(int, pthread_cond_destroy, (pthread_cond_t *cond))
 {
-   struct cobalt_cond_shadow *_cond = &((union cobalt_cond_union 
*)cond)->shadow_cond;
+   struct cobalt_cond_shadow *_cond =
+   &((union cobalt_cond_union *)cond)->shadow_cond;
+
+   if (unlikely(_cond->magic != COBALT_COND_MAGIC))
+   return (cobalt_cond_autoinit_type(cond) < 0) ? EINVAL : 0;
 
return -XENOMAI_SYSCALL1( sc_cobalt_cond_destroy, _cond);
 }
@@ -193,12 +223,6 @@ static void __pthread_cond_cleanup(void *data)
c->mutex->lockcnt = c->count;
 }
 
-static int __attribute__((cold)) cobalt_cond_autoinit(pthread_cond_t *cond)
-{
-   return __COBALT(pthread_cond_init(cond, NULL));
-}
-
-
 /**
  * Wait on a condition variable.
  *
@@ -262,10 +286,10 @@ COBALT_IMPL(int, pthread_cond_wait, (pthread_cond_t 
*cond, pthread_mutex_t *mute
if (_mx->magic != COBALT_MUTEX_MAGIC)
return EINVAL;
 
-   if (_cnd->magic != COBALT_COND_MAGIC)
-   goto autoinit;
+   err = cobalt_cond_autoinit((union cobalt_cond_union *)cond);
+   if (err)
+   return err;
 
-  cont:
if (_mx->attr.type == PTHREAD_MUTEX_ERRORCHECK) {
xnhandle_t cur = cobalt_get_current();
 
@@ -297,12 +321,6 @@ COBALT_IMPL(int, pthread_cond_wait, (pthread_cond_t *cond, 
pthread_mutex_t *mute
pthread_testcancel();
 
return -err ?: -c.err;
-
-  autoinit:
-   err = cobalt_cond_autoinit(cond);
-   if (err)
-   return err;
-   goto cont;
 }
 
 /**
@@ -357,10 +375,10 @@ COBALT_IMPL(int, pthread_cond_timedwait, (pthread_cond_t 
*cond,
if (_mx->magic != COBALT_MUTEX_MAGIC)
return EINVAL;
 
-   if (_cnd->magic != COBALT_COND_MAGIC)
-   goto autoinit;
+   err = cobalt_cond_autoinit((union cobalt_cond_union *)cond);
+   if (err)
+   return err;
 
-  cont:
if (_mx->attr.type == PTHREAD_MUTEX_ERRORCHECK) {
xnhandle_t cur = cobalt_get_current();
 
@@ -391,12 +409,6 @@ COBALT_IMPL(int, pthread_cond_timedwait, (pthread_cond_t 
*cond,
pthread_testcancel();
 
return -err ?: -c.err;
-
-  autoinit:
-   err = cobalt_cond_autoinit(cond);
-   if (err)
-   return err;
-   goto cont;
 }
 
 /**
@@ -431,10 +443,10 @@ COBALT_IMPL(int, pthread_cond_signal, (pthread_cond_t 
*cond))
__u32 flags;
int err;
 
-   if (_cnd->magic != COBALT_COND_MAGIC)
-   goto autoinit;
+   err = cobalt_cond_autoinit((union cobalt_cond_union *)cond);
+   if (err)
+   return err;
 
-  cont:
mutex_state = get_mutex_state(_cnd);
if (mutex_state == NULL)
return 0;   /* Fast path, no waiter. */
@@ -455,12 +467,6 @@ COBALT_IMPL(int, pthread_cond_signal, (pthread_cond_t 
*cond))
cond_state->pending_signals = pending_signals + 1;
 
return 0;
-
-  autoinit:
-   err = cobalt_cond_autoinit(cond);
-   if (err)
-   return err;
-   goto cont;
 }
 
 /**
@@ -491,10 +497,10 @@ COBALT_IMPL(int, pthread_cond_broadcast, (pthread_cond_t 
*cond))
__u32 flags;
int err;
 
-   if (_cnd->magic != COBALT_COND_MAGIC)
-   goto autoinit;
+   err = cobalt_cond_autoinit((union cobalt_cond_union *)cond);
+   if (

[PATCH v3 1/5] libcobalt: improve mutex autoinit support

2019-04-10 Thread Norbert Lange via Xenomai
contrary to some comments, mutexes are automatically
initialised on lock/unlock.
Correct the destroy method to not report an
error on such mutexes.

{get,set}prioceiling requires mutexes that were explicitly
initialised, so no change needed there

Signed-off-by: Norbert Lange 
---
 lib/cobalt/mutex.c | 180 +++--
 1 file changed, 94 insertions(+), 86 deletions(-)

diff --git a/lib/cobalt/mutex.c b/lib/cobalt/mutex.c
index ed32bba32..2748850e2 100644
--- a/lib/cobalt/mutex.c
+++ b/lib/cobalt/mutex.c
@@ -164,70 +164,52 @@ COBALT_IMPL(int, pthread_mutex_init, (pthread_mutex_t 
*mutex,
 }
 
 /**
- * Destroy a mutex.
- *
- * This service destroys the mutex @a mx, if it is unlocked and not referenced
- * by any condition variable. The mutex becomes invalid for all mutex services
- * (they all return the EINVAL error) except pthread_mutex_init().
- *
- * @param mutex the mutex to be destroyed.
- *
- * @return 0 on success,
- * @return an error number if:
- * - EINVAL, the mutex @a mx is invalid;
- * - EPERM, the mutex is not process-shared and does not belong to the current
- *   process;
- * - EBUSY, the mutex is locked, or used by a condition variable.
+ * Test if a mutex structure contains a valid autoinitializer.
  *
- * @see
- * http://www.opengroup.org/onlinepubs/95399/functions/pthread_mutex_destroy.html";>
- * Specification.
- *
- * @apitags{thread-unrestricted}
+ * @return the mutex type on success,
+ * @return -1 if not in supported autoinitializer state
  */
-COBALT_IMPL(int, pthread_mutex_destroy, (pthread_mutex_t *mutex))
-{
-   struct cobalt_mutex_shadow *_mutex =
-   &((union cobalt_mutex_union *)mutex)->shadow_mutex;
-   int err;
-
-   if (_mutex->magic != COBALT_MUTEX_MAGIC)
-   return EINVAL;
-
-   err = XENOMAI_SYSCALL1(sc_cobalt_mutex_destroy, _mutex);
-
-   return -err;
-}
-
-static int __attribute__((cold)) cobalt_mutex_autoinit(pthread_mutex_t *mutex)
+static int __attribute__((cold))
+   cobalt_mutex_autoinit_type(const pthread_mutex_t *mutex)
 {
-   static pthread_mutex_t uninit_normal_mutex =
-   PTHREAD_MUTEX_INITIALIZER;
+   static const pthread_mutex_t mutex_initializers[] = {
+#if HAVE_DECL_PTHREAD_ERRORCHECK_MUTEX_INITIALIZER_NP
+   PTHREAD_ERRORCHECK_MUTEX_INITIALIZER_NP,
+#endif
 #if HAVE_DECL_PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP
-   static pthread_mutex_t uninit_recursive_mutex =
-   PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP;
+   PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP,
 #endif
+   PTHREAD_MUTEX_INITIALIZER
+   };
+   static const int mutex_types[] = {
 #if HAVE_DECL_PTHREAD_ERRORCHECK_MUTEX_INITIALIZER_NP
-   static pthread_mutex_t uninit_errorcheck_mutex =
-   PTHREAD_ERRORCHECK_MUTEX_INITIALIZER_NP;
+   PTHREAD_MUTEX_ERRORCHECK_NP,
 #endif
-   struct cobalt_mutex_shadow *_mutex =
-   &((union cobalt_mutex_union *)mutex)->shadow_mutex;
+#if HAVE_DECL_PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP
+   PTHREAD_MUTEX_RECURSIVE_NP,
+#endif
+   PTHREAD_MUTEX_DEFAULT
+   };
+   int i;
+
+   for (i = sizeof(mutex_types) / sizeof(mutex_types[0]); i > 0; --i) {
+   if (memcmp(mutex, &mutex_initializers[i - 1],
+   sizeof(mutex_initializers[0])) == 0)
+   return mutex_types[i - 1];
+   }
+   return -1;
+}
+
+static int __attribute__((cold))
+   cobalt_mutex_doautoinit(union cobalt_mutex_union *umutex)
+{
+   struct cobalt_mutex_shadow *_mutex = &umutex->shadow_mutex;
int err __attribute__((unused));
pthread_mutexattr_t mattr;
int ret = 0, type;
 
-   if (memcmp(mutex, &uninit_normal_mutex, sizeof(*mutex)) == 0)
-   type = PTHREAD_MUTEX_DEFAULT;
-#if HAVE_DECL_PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP
-   else if (memcmp(mutex, &uninit_recursive_mutex, sizeof(*mutex)) == 0)
-   type = PTHREAD_MUTEX_RECURSIVE_NP;
-#endif
-#if HAVE_DECL_PTHREAD_ERRORCHECK_MUTEX_INITIALIZER_NP
-   else if (memcmp(mutex, &uninit_errorcheck_mutex, sizeof(*mutex)) == 0)
-   type = PTHREAD_MUTEX_ERRORCHECK_NP;
-#endif
-   else
+   type = cobalt_mutex_autoinit_type(&umutex->native_mutex);
+   if (type < 0)
return EINVAL;
 
pthread_mutexattr_init(&mattr);
@@ -238,7 +220,8 @@ static int __attribute__((cold)) 
cobalt_mutex_autoinit(pthread_mutex_t *mutex)
goto out;
}
if (_mutex->magic != COBALT_MUTEX_MAGIC)
-   ret = __COBALT(pthread_mutex_init(mutex, &mattr));
+   ret = __COBALT(pthread_mutex_init(&umutex->native_mutex,
+   &mattr));
err = __COBALT(pthread_mutex_unlock(cobalt_autoinit_mutex));
if (err) {
if (ret == 0)
@@ -251,6 +234,49 @@ static int __attribute__((cold)) 
cobalt_mutex_autoinit(p

[no subject]

2019-04-10 Thread Norbert Lange via Xenomai
V3 of the patchset, corrected many checkstyle issues,
simplified condvar autoinit.

I did not use ARRAY_SIZE, as that would need another include.





[PATCH v3 4/5] libcobalt: improve documentation regarding condvar initializers

2019-04-10 Thread Norbert Lange via Xenomai
Signed-off-by: Norbert Lange 
---
 lib/cobalt/cond.c | 10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/lib/cobalt/cond.c b/lib/cobalt/cond.c
index 9553824c2..e66b20922 100644
--- a/lib/cobalt/cond.c
+++ b/lib/cobalt/cond.c
@@ -47,9 +47,13 @@
  * several processes (it may not be shared by default, see
  * pthread_condattr_setpshared()).
  *
- * Note that only pthread_cond_init() may be used to initialize a condition
- * variable, using the static initializer @a PTHREAD_COND_INITIALIZER is
- * not supported.
+ * Note that pthread_cond_init() should be used to initialize a condition
+ * variable, using the static initializer @a PTHREAD_COND_INITIALIZER will
+ * delay the initialization to the first method called on the condition
+ * variable and will most likely introduce switches to secondary mode.
+ * The documentation (and specifically api-tags) of the
+ * condition variable services assumes the condition variable was explicitly
+ * initialised with pthread_cond_init().
  *
  *@{
  */
-- 
2.20.1




[PATCH v3 2/5] libcobalt: improve documentation regarding mutex initializers

2019-04-10 Thread Norbert Lange via Xenomai
Signed-off-by: Norbert Lange 
---
 lib/cobalt/mutex.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/lib/cobalt/mutex.c b/lib/cobalt/mutex.c
index 2748850e2..2f7595b50 100644
--- a/lib/cobalt/mutex.c
+++ b/lib/cobalt/mutex.c
@@ -49,8 +49,12 @@
  * By default, Cobalt mutexes are of the normal type, use no
  * priority protocol and may not be shared between several processes.
  *
- * Note that only pthread_mutex_init() may be used to initialize a mutex, using
- * the static initializer @a PTHREAD_MUTEX_INITIALIZER is not supported.
+ * Note that pthread_mutex_init() should be used to initialize a mutex, using
+ * the static initializer @a PTHREAD_MUTEX_INITIALIZER will delay the
+ * initialization to the first method called on the mutex and will
+ * most likely introduce switches to secondary mode.
+ * The documentation (and specifically api-tags) of the mutex services assumes
+ * a mutex was explicitly initialised with pthread_mutex_init().
  *
  *@{
  */
-- 
2.20.1




[PATCH v3 5/5] smokey: add tests for mutex/condvar autoinit

2019-04-10 Thread Norbert Lange via Xenomai
add a few testcases where destroy is called as first function,
and test failure if the state is a non-standard initializer.

Signed-off-by: Norbert Lange 
---
 testsuite/smokey/posix-cond/posix-cond.c   | 15 +++
 testsuite/smokey/posix-mutex/posix-mutex.c | 52 ++
 2 files changed, 67 insertions(+)

diff --git a/testsuite/smokey/posix-cond/posix-cond.c 
b/testsuite/smokey/posix-cond/posix-cond.c
index 153c64599..53d707d04 100644
--- a/testsuite/smokey/posix-cond/posix-cond.c
+++ b/testsuite/smokey/posix-cond/posix-cond.c
@@ -198,6 +198,20 @@ static void *cond_signaler(void *cookie)
return NULL;
 }
 
+static void autoinit_simple_conddestroy(void)
+{
+   pthread_cond_t cond = PTHREAD_COND_INITIALIZER;
+   pthread_cond_t cond2 = PTHREAD_COND_INITIALIZER;
+   unsigned int invalmagic = ~0x86860505; // ~COBALT_COND_MAGIC
+
+   memcpy((char *)&cond2 + sizeof(cond2) - sizeof(invalmagic),
+   &invalmagic, sizeof(invalmagic));
+
+   smokey_trace("%s", __func__);
+   check("cond_destroy", cond_destroy(&cond), 0);
+   check("cond_destroy invalid", cond_destroy(&cond2), -EINVAL);
+}
+
 static void autoinit_simple_condwait(void)
 {
pthread_cond_t cond = PTHREAD_COND_INITIALIZER;
@@ -731,6 +745,7 @@ int run_posix_cond(struct smokey_test *t, int argc, char 
*const argv[])
sparam.sched_priority = 2;
pthread_setschedparam(pthread_self(), SCHED_FIFO, &sparam);
 
+   autoinit_simple_conddestroy();
autoinit_simple_condwait();
simple_condwait();
relative_condwait();
diff --git a/testsuite/smokey/posix-mutex/posix-mutex.c 
b/testsuite/smokey/posix-mutex/posix-mutex.c
index 182f8c0e5..6454a8d14 100644
--- a/testsuite/smokey/posix-mutex/posix-mutex.c
+++ b/testsuite/smokey/posix-mutex/posix-mutex.c
@@ -296,6 +296,31 @@ static int do_contend(pthread_mutex_t *mutex, int type)
return 0;
 }
 
+static int do_destroy(pthread_mutex_t *mutex, pthread_mutex_t *invalmutex,
+   int type)
+{
+   int ret;
+
+   if (!__T(ret, pthread_mutex_destroy(mutex)))
+   return ret;
+   if (!__F(ret, pthread_mutex_destroy(invalmutex)) &&
+   __Tassert(ret == -EINVAL))
+   return -1;
+   return 0;
+}
+
+static int static_init_normal_destroy(void)
+{
+   pthread_mutex_t mutex = PTHREAD_MUTEX_INITIALIZER;
+   pthread_mutex_t invalmutex = PTHREAD_MUTEX_INITIALIZER;
+
+   unsigned int invalmagic = ~0x86860303; // ~COBALT_MUTEX_MAGIC
+
+   memcpy((char *)&invalmutex + sizeof(invalmutex) - sizeof(invalmagic),
+   &invalmagic, sizeof(invalmagic));
+   return do_destroy(&mutex, &invalmutex, PTHREAD_MUTEX_NORMAL);
+}
+
 static int static_init_normal_contend(void)
 {
pthread_mutex_t mutex = PTHREAD_MUTEX_INITIALIZER;
@@ -320,6 +345,18 @@ static int dynamic_init_normal_contend(void)
return __dynamic_init_contend(PTHREAD_MUTEX_NORMAL);
 }
 
+static int static_init_recursive_destroy(void)
+{
+   pthread_mutex_t mutex = PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP;
+   pthread_mutex_t invalmutex = PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP;
+
+   unsigned int invalmagic = ~0x86860303; // ~COBALT_MUTEX_MAGIC
+
+   memcpy((char *)&invalmutex + sizeof(invalmutex) - sizeof(invalmagic),
+   &invalmagic, sizeof(invalmagic));
+   return do_destroy(&mutex, &invalmutex, PTHREAD_MUTEX_RECURSIVE);
+}
+
 static int static_init_recursive_contend(void)
 {
pthread_mutex_t mutex = PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP;
@@ -332,6 +369,18 @@ static int dynamic_init_recursive_contend(void)
return __dynamic_init_contend(PTHREAD_MUTEX_RECURSIVE);
 }
 
+static int static_init_errorcheck_destroy(void)
+{
+   pthread_mutex_t mutex = PTHREAD_ERRORCHECK_MUTEX_INITIALIZER_NP;
+   pthread_mutex_t invalmutex = PTHREAD_ERRORCHECK_MUTEX_INITIALIZER_NP;
+
+   unsigned int invalmagic = ~0x86860303; // ~COBALT_MUTEX_MAGIC
+
+   memcpy((char *)&invalmutex + sizeof(invalmutex) - sizeof(invalmagic),
+   &invalmagic, sizeof(invalmagic));
+   return do_destroy(&mutex, &invalmutex, PTHREAD_MUTEX_ERRORCHECK);
+}
+
 static int static_init_errorcheck_contend(void)
 {
pthread_mutex_t mutex = PTHREAD_ERRORCHECK_MUTEX_INITIALIZER_NP;
@@ -991,10 +1040,13 @@ static int run_posix_mutex(struct smokey_test *t, int 
argc, char *const argv[])
SCHED_FIFO, ¶m)))
return ret;
 
+   do_test(static_init_normal_destroy, MAX_100_MS);
do_test(static_init_normal_contend, MAX_100_MS);
do_test(dynamic_init_normal_contend, MAX_100_MS);
+   do_test(static_init_recursive_destroy, MAX_100_MS);
do_test(static_init_recursive_contend, MAX_100_MS);
do_test(dynamic_init_recursive_contend, MAX_100_MS);
+   do_test(static_init_errorcheck_destroy, MAX_100_MS);
do_test(static_init_errorcheck_contend, MAX_100_MS);
do_test

[no subject]

2019-04-10 Thread Norbert Lange via Xenomai
V2 of the patchset. Fixed checkstyle issues, better identation,
and aded casts to silence (false) pedantic warnings.





[PATCH 1/1] cobalt: mode argument from open forwarded for O_TMPFILE

2019-04-10 Thread Norbert Lange via Xenomai
The optional mode argument (open is a vararg function),
was only be read and forwarded if the O_CREAT flag is set.

That is not complete, as O_TMPFILE will require this
argument aswell. Fixed in this commit, and a fallback definition
of O_TMPFILE is added, incase libcobalt is built against an
library lacking this macro.

Signed-off-by: Norbert Lange 
---
 lib/cobalt/rtdm.c | 10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/lib/cobalt/rtdm.c b/lib/cobalt/rtdm.c
index 6b8898e70..176210ddc 100644
--- a/lib/cobalt/rtdm.c
+++ b/lib/cobalt/rtdm.c
@@ -30,6 +30,12 @@
 #include 
 #include "internal.h"
 
+/* support for very old c libraries not supporting O_TMPFILE */
+#ifndef O_TMPFILE
+#define O_TMPFILE (02000 | 020)
+#endif
+
+
 static inline int set_errno(int ret)
 {
if (ret >= 0)
@@ -65,7 +71,7 @@ COBALT_IMPL(int, open, (const char *path, int oflag, ...))
mode_t mode = 0;
va_list ap;
 
-   if (oflag & O_CREAT) {
+   if ((oflag & O_CREAT)  || (oflag & O_TMPFILE) == O_TMPFILE) {
va_start(ap, oflag);
mode = va_arg(ap, int);
va_end(ap);
@@ -79,7 +85,7 @@ COBALT_IMPL(int, open64, (const char *path, int oflag, ...))
mode_t mode = 0;
va_list ap;
 
-   if (oflag & O_CREAT) {
+   if ((oflag & O_CREAT)  || (oflag & O_TMPFILE) == O_TMPFILE) {
va_start(ap, oflag);
mode = va_arg(ap, int);
va_end(ap);
-- 
2.20.1




[PATCH v2 1/2] Rename __ctz to xenomai_count_trailing_zeros

2019-04-10 Thread Norbert Lange via Xenomai
Because of conflicts with libc++ (v1/bit include file).
Simplify the macro as there shouldn't be any bad cornercases

Signed-off-by: Norbert Lange 
---
 include/boilerplate/compiler.h| 31 ++-
 lib/boilerplate/heapmem.c |  2 +-
 lib/copperplate/heapobj-pshared.c |  2 +-
 3 files changed, 12 insertions(+), 23 deletions(-)

diff --git a/include/boilerplate/compiler.h b/include/boilerplate/compiler.h
index 0fcc17be1..0cd71b80a 100644
--- a/include/boilerplate/compiler.h
+++ b/include/boilerplate/compiler.h
@@ -71,27 +71,16 @@
 #ifdef __cplusplus
 extern "C" {
 #endif
-   
+
 void __invalid_operand_size(void);
 
-#define __ctz(__v) \
-   ({  \
-   int __ret;  \
-   if (!__v)   \
-   __ret = sizeof(__v) * 8;\
-   else\
-   switch (sizeof(__v)) {  \
-   case sizeof(int):   \
-   __ret = __builtin_ctz((unsigned int)__v); \
-   break;  \
-   case sizeof(long long): \
-   __ret = __builtin_ctzll(__v);   \
-   break;  \
-   default:\
-   __invalid_operand_size();   \
-   }   \
-   __ret;  \
-   })
+#define xenomai_count_trailing_zeros(x)
\
+   ((x) == 0 ? (int)(sizeof(x) * __CHAR_BIT__) \
+   : sizeof(x) <= sizeof(unsigned int) ?   \
+   __builtin_ctz((unsigned int)x)  \
+   : sizeof(x) <= sizeof(unsigned long) ?  \
+   __builtin_ctzl((unsigned long)x)\
+   : __builtin_ctzll(x))
 
 #define xenomai_count_leading_zeros(__v)   \
({  \
@@ -111,9 +100,9 @@ void __invalid_operand_size(void);
}   \
__ret;  \
})
-   
+
 #ifdef __cplusplus
 }
 #endif
-   
+
 #endif /* _BOILERPLATE_COMPILER_H */
diff --git a/lib/boilerplate/heapmem.c b/lib/boilerplate/heapmem.c
index 8728e0d15..e6369c715 100644
--- a/lib/boilerplate/heapmem.c
+++ b/lib/boilerplate/heapmem.c
@@ -476,7 +476,7 @@ void *heapmem_alloc(struct heap_memory *heap, size_t size)
bmask = ext->pagemap[pg].map;
if (bmask == -1U)
break;
-   b = __ctz(~bmask);
+   b = xenomai_count_trailing_zeros(~bmask);
 
/*
 * Got one block from the heading per-bucket
diff --git a/lib/copperplate/heapobj-pshared.c 
b/lib/copperplate/heapobj-pshared.c
index 5310d9092..d6cc51ae9 100644
--- a/lib/copperplate/heapobj-pshared.c
+++ b/lib/copperplate/heapobj-pshared.c
@@ -529,7 +529,7 @@ static void *sheapmem_alloc(struct shared_heap_memory 
*heap, size_t size)
bmask = ext->pagemap[pg].map;
if (bmask == -1U)
break;
-   b = __ctz(~bmask);
+   b = xenomai_count_trailing_zeros(~bmask);
 
/*
 * Got one block from the heading per-bucket
-- 
2.20.1




[PATCH v2 2/2] Simplify xenomai_count_leading_zeros

2019-04-10 Thread Norbert Lange via Xenomai
Covers now all standard integer types,
no need for corner cases.

Signed-off-by: Norbert Lange 
---
 include/boilerplate/compiler.h | 28 
 1 file changed, 8 insertions(+), 20 deletions(-)

diff --git a/include/boilerplate/compiler.h b/include/boilerplate/compiler.h
index 0cd71b80a..94b9f8cad 100644
--- a/include/boilerplate/compiler.h
+++ b/include/boilerplate/compiler.h
@@ -72,8 +72,6 @@
 extern "C" {
 #endif
 
-void __invalid_operand_size(void);
-
 #define xenomai_count_trailing_zeros(x)
\
((x) == 0 ? (int)(sizeof(x) * __CHAR_BIT__) \
: sizeof(x) <= sizeof(unsigned int) ?   \
@@ -82,24 +80,14 @@ void __invalid_operand_size(void);
__builtin_ctzl((unsigned long)x)\
: __builtin_ctzll(x))
 
-#define xenomai_count_leading_zeros(__v)   \
-   ({  \
-   int __ret;  \
-   if (!__v)   \
-   __ret = sizeof(__v) * 8;\
-   else\
-   switch (sizeof(__v)) {  \
-   case sizeof(int):   \
-   __ret = __builtin_clz((unsigned int)__v); \
-   break;  \
-   case sizeof(long long): \
-   __ret = __builtin_clzll(__v);   \
-   break;  \
-   default:\
-   __invalid_operand_size();   \
-   }   \
-   __ret;  \
-   })
+#define xenomai_count_leading_zeros(x) \
+   ((x) == 0 ? (int)(sizeof(x) * __CHAR_BIT__) \
+   : sizeof(x) <= sizeof(unsigned int) ?   \
+   __builtin_clz((unsigned int)x) +\
+   (int)(sizeof(unsigned int) - sizeof(x)) \
+   : sizeof(x) <= sizeof(unsigned long) ?  \
+   __builtin_clzl((unsigned long)x)\
+   : __builtin_clzll(x))
 
 #ifdef __cplusplus
 }
-- 
2.20.1




Re: (unknown)

2019-04-10 Thread Jan Kiszka via Xenomai

On 10.04.19 13:14, Norbert Lange via Xenomai wrote:

V3 of the patchset, corrected many checkstyle issues,
simplified condvar autoinit.



Thanks for the update!


I did not use ARRAY_SIZE, as that would need another include.



Ah, we do not have this construct in lib/ so far.

There are private ARRAY_LEN macros in lib/analogy/calibration.c and 
utils/analogy/analogy_calibrate.h. Well, something that can be consolidates later.


Jan

--
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux



Re: [PATCH] ci: Tune config

2019-04-10 Thread Jan Kiszka via Xenomai

On 10.04.19 10:42, Roman Stratiienko wrote:

I did measurements after clearing cache 'ccache -C'

I assume that 600mb in current statistic is due to multiple build of different 
source dependencies due to enabled DEBUG INFO config. Old cache should be 
invalidated and cleaned automatically as size goes up to the limit.




Indeed, things piled up.

We can keep the lower limit for now and see how this evolve.

Jan



ср, 10 апр. 2019 г., 08:34 Jan Kiszka >:


On 09.04.19 22:47, Roman Stratiienko wrote:
 >
 > I have similar issue some time ago on another project, but due to lack of
time
 > and low priority it was unsolved.
 > And you've found the root cause and it is great, thanks!.

At least it looks like as the rebuild no only takes 15 minutes.

 >
 > I did some measurements of ccache size, and results is following:
 > - 4.14 arm64 - cache size - 232.7 MB
 > - 4.19 arm - cache size - 246.4 MB
 > - Others are even less.
 >
 > So I suggest to left it 400MB, thus not to use too much disk space of
travis's
 > servers.

Look at the statistics you added to our build:

4.14 arm64: 601.6 MB
4.19 arm:   557.7 MB
4.14 x86:   292.5 MB

If you cap the size, ccache may drop artifacts during the build, then 
refill,
but may stay below the limit at the end. Still, the cache will be 
incomplete.

Jan

-- 
Siemens AG, Corporate Technology, CT RDA IOT SES-DE

Corporate Competence Center Embedded Linux



--
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux



Re: (unknown)

2019-04-10 Thread Jan Kiszka via Xenomai

On 10.04.19 13:17, Norbert Lange via Xenomai wrote:

V2 of the patchset. Fixed checkstyle issues, better identation,
and aded casts to silence (false) pedantic warnings.



Both applied to next, thanks.

You probably want to edit your cover letter subject as well - or use git 
format-patch.


Jan

--
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux



Re: [PATCH 1/1] cobalt: mode argument from open forwarded for O_TMPFILE

2019-04-10 Thread Jan Kiszka via Xenomai

On 10.04.19 13:18, Norbert Lange via Xenomai wrote:

The optional mode argument (open is a vararg function),
was only be read and forwarded if the O_CREAT flag is set.

That is not complete, as O_TMPFILE will require this
argument aswell. Fixed in this commit, and a fallback definition
of O_TMPFILE is added, incase libcobalt is built against an
library lacking this macro.

Signed-off-by: Norbert Lange 
---
  lib/cobalt/rtdm.c | 10 --
  1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/lib/cobalt/rtdm.c b/lib/cobalt/rtdm.c
index 6b8898e70..176210ddc 100644
--- a/lib/cobalt/rtdm.c
+++ b/lib/cobalt/rtdm.c
@@ -30,6 +30,12 @@
  #include 
  #include "internal.h"
  
+/* support for very old c libraries not supporting O_TMPFILE */

+#ifndef O_TMPFILE
+#define O_TMPFILE (02000 | 020)
+#endif
+
+
  static inline int set_errno(int ret)
  {
if (ret >= 0)
@@ -65,7 +71,7 @@ COBALT_IMPL(int, open, (const char *path, int oflag, ...))
mode_t mode = 0;
va_list ap;
  
-	if (oflag & O_CREAT) {

+   if ((oflag & O_CREAT)  || (oflag & O_TMPFILE) == O_TMPFILE) {
va_start(ap, oflag);
mode = va_arg(ap, int);
va_end(ap);
@@ -79,7 +85,7 @@ COBALT_IMPL(int, open64, (const char *path, int oflag, ...))
mode_t mode = 0;
va_list ap;
  
-	if (oflag & O_CREAT) {

+   if ((oflag & O_CREAT)  || (oflag & O_TMPFILE) == O_TMPFILE) {
va_start(ap, oflag);
mode = va_arg(ap, int);
va_end(ap);



Thanks, applied.

Jan

--
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux



[PATCH v2 1/1] cobalt: mode argument from open forwarded for O_TMPFILE

2019-04-10 Thread Norbert Lange via Xenomai
The optional mode argument (open is a vararg function),
was only be read and forwarded if the O_CREAT flag is set.

That is not complete, as O_TMPFILE will require this
argument aswell. Fixed in this commit, and a fallback definition
of O_TMPFILE is added, incase libcobalt is built against an
library lacking this macro.

Signed-off-by: Norbert Lange 
---
 lib/cobalt/rtdm.c | 10 --
 lib/cobalt/wrappers.c |  9 +++--
 2 files changed, 15 insertions(+), 4 deletions(-)

diff --git a/lib/cobalt/rtdm.c b/lib/cobalt/rtdm.c
index 6b8898e70..176210ddc 100644
--- a/lib/cobalt/rtdm.c
+++ b/lib/cobalt/rtdm.c
@@ -30,6 +30,12 @@
 #include 
 #include "internal.h"
 
+/* support for very old c libraries not supporting O_TMPFILE */
+#ifndef O_TMPFILE
+#define O_TMPFILE (02000 | 020)
+#endif
+
+
 static inline int set_errno(int ret)
 {
if (ret >= 0)
@@ -65,7 +71,7 @@ COBALT_IMPL(int, open, (const char *path, int oflag, ...))
mode_t mode = 0;
va_list ap;
 
-   if (oflag & O_CREAT) {
+   if ((oflag & O_CREAT)  || (oflag & O_TMPFILE) == O_TMPFILE) {
va_start(ap, oflag);
mode = va_arg(ap, int);
va_end(ap);
@@ -79,7 +85,7 @@ COBALT_IMPL(int, open64, (const char *path, int oflag, ...))
mode_t mode = 0;
va_list ap;
 
-   if (oflag & O_CREAT) {
+   if ((oflag & O_CREAT)  || (oflag & O_TMPFILE) == O_TMPFILE) {
va_start(ap, oflag);
mode = va_arg(ap, int);
va_end(ap);
diff --git a/lib/cobalt/wrappers.c b/lib/cobalt/wrappers.c
index 20ad63a61..323f60b92 100644
--- a/lib/cobalt/wrappers.c
+++ b/lib/cobalt/wrappers.c
@@ -44,6 +44,11 @@
 #include 
 #include 
 
+/* support for very old c libraries not supporting O_TMPFILE */
+#ifndef O_TMPFILE
+#define O_TMPFILE (02000 | 020)
+#endif
+
 /* sched */
 __weak
 int __real_pthread_setschedparam(pthread_t thread,
@@ -174,7 +179,7 @@ int __real_open(const char *path, int oflag, ...)
mode_t mode = 0;
va_list ap;
 
-   if (oflag & O_CREAT) {
+   if ((oflag & O_CREAT) || (oflag & O_TMPFILE) == O_TMPFILE) {
va_start(ap, oflag);
mode = va_arg(ap, mode_t);
va_end(ap);
@@ -190,7 +195,7 @@ int __real_open64(const char *path, int oflag, ...)
mode_t mode = 0;
va_list ap;
 
-   if (oflag & O_CREAT) {
+   if ((oflag & O_CREAT) || (oflag & O_TMPFILE) == O_TMPFILE) {
va_start(ap, oflag);
mode = va_arg(ap, mode_t);
va_end(ap);
-- 
2.20.1




[no subject]

2019-04-10 Thread Norbert Lange via Xenomai
V2 now also fixes the wrappers.

Btw. wouldnt it be possible to just do away with the ugly vaargs?
I tested a few architectures (x86, arm mips, both 32 and 64 bit)
and the function call singature stays the same whether a
function has varagrs or a fixed amount of arguments.

The wrappers could then be oblivous to such wacky special cases.

Torvalds seems to have that opinion aswell:
https://lkml.org/lkml/2014/10/30/812





Re: [PATCH v2 1/1] cobalt: mode argument from open forwarded for O_TMPFILE

2019-04-10 Thread Jan Kiszka via Xenomai

On 10.04.19 16:25, Norbert Lange via Xenomai wrote:

The optional mode argument (open is a vararg function),
was only be read and forwarded if the O_CREAT flag is set.

That is not complete, as O_TMPFILE will require this
argument aswell. Fixed in this commit, and a fallback definition
of O_TMPFILE is added, incase libcobalt is built against an
library lacking this macro.

Signed-off-by: Norbert Lange 
---
  lib/cobalt/rtdm.c | 10 --
  lib/cobalt/wrappers.c |  9 +++--
  2 files changed, 15 insertions(+), 4 deletions(-)

diff --git a/lib/cobalt/rtdm.c b/lib/cobalt/rtdm.c
index 6b8898e70..176210ddc 100644
--- a/lib/cobalt/rtdm.c
+++ b/lib/cobalt/rtdm.c
@@ -30,6 +30,12 @@
  #include 
  #include "internal.h"
  
+/* support for very old c libraries not supporting O_TMPFILE */

+#ifndef O_TMPFILE
+#define O_TMPFILE (02000 | 020)
+#endif
+
+
  static inline int set_errno(int ret)
  {
if (ret >= 0)
@@ -65,7 +71,7 @@ COBALT_IMPL(int, open, (const char *path, int oflag, ...))
mode_t mode = 0;
va_list ap;
  
-	if (oflag & O_CREAT) {

+   if ((oflag & O_CREAT)  || (oflag & O_TMPFILE) == O_TMPFILE) {
va_start(ap, oflag);
mode = va_arg(ap, int);
va_end(ap);
@@ -79,7 +85,7 @@ COBALT_IMPL(int, open64, (const char *path, int oflag, ...))
mode_t mode = 0;
va_list ap;
  
-	if (oflag & O_CREAT) {

+   if ((oflag & O_CREAT)  || (oflag & O_TMPFILE) == O_TMPFILE) {
va_start(ap, oflag);
mode = va_arg(ap, int);
va_end(ap);
diff --git a/lib/cobalt/wrappers.c b/lib/cobalt/wrappers.c
index 20ad63a61..323f60b92 100644
--- a/lib/cobalt/wrappers.c
+++ b/lib/cobalt/wrappers.c
@@ -44,6 +44,11 @@
  #include 
  #include 
  
+/* support for very old c libraries not supporting O_TMPFILE */

+#ifndef O_TMPFILE
+#define O_TMPFILE (02000 | 020)
+#endif
+
  /* sched */
  __weak
  int __real_pthread_setschedparam(pthread_t thread,
@@ -174,7 +179,7 @@ int __real_open(const char *path, int oflag, ...)
mode_t mode = 0;
va_list ap;
  
-	if (oflag & O_CREAT) {

+   if ((oflag & O_CREAT) || (oflag & O_TMPFILE) == O_TMPFILE) {
va_start(ap, oflag);
mode = va_arg(ap, mode_t);
va_end(ap);
@@ -190,7 +195,7 @@ int __real_open64(const char *path, int oflag, ...)
mode_t mode = 0;
va_list ap;
  
-	if (oflag & O_CREAT) {

+   if ((oflag & O_CREAT) || (oflag & O_TMPFILE) == O_TMPFILE) {
va_start(ap, oflag);
mode = va_arg(ap, mode_t);
va_end(ap);



OK, taken this one now, instead of v1.

Jan

--
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux



Re: (unknown)

2019-04-10 Thread Jan Kiszka via Xenomai

On 10.04.19 13:14, Norbert Lange via Xenomai wrote:

V3 of the patchset, corrected many checkstyle issues,
simplified condvar autoinit.

I did not use ARRAY_SIZE, as that would need another include.



All applied now. Patch 1 was not cleanly based on next, though. I think some 
local style cleanup was missing.


Jan

--
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux



Re: (unknown)

2019-04-10 Thread Jan Kiszka via Xenomai

[re-adding the list]

On 10.04.19 16:44, Lange Norbert wrote:




-Original Message-
From: Xenomai  On Behalf Of Jan Kiszka via
Xenomai
Sent: Mittwoch, 10. April 2019 16:36
To: Norbert Lange ; xenomai@xenomai.org
Subject: Re: (unknown)

E-MAIL FROM A NON-ANDRITZ SOURCE: AS A SECURITY MEASURE, PLEASE
EXERCISE CAUTION WITH E-MAIL CONTENT AND ANY LINKS OR ATTACHMENTS.


On 10.04.19 13:14, Norbert Lange via Xenomai wrote:

V3 of the patchset, corrected many checkstyle issues, simplified
condvar autoinit.

I did not use ARRAY_SIZE, as that would need another include.



All applied now. Patch 1 was not cleanly based on next, though. I think some
local style cleanup was missing.


I based all patches on master, thought this is the primary development branch?



Line 566 in lib/cobalt/mutex.c had a trailing tab, your patch context did not, 
and that made the application fail. Maybe that was removed while transporting 
the patch into your mail client - better use git send-email in that case.


Jan

--
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux



RE: (unknown)

2019-04-10 Thread Lange Norbert via Xenomai


> -Original Message-
> From: Jan Kiszka 
> Sent: Mittwoch, 10. April 2019 16:48
> To: Lange Norbert ; Xenomai
> 
> Subject: Re: (unknown)
>
> E-MAIL FROM A NON-ANDRITZ SOURCE: AS A SECURITY MEASURE, PLEASE
> EXERCISE CAUTION WITH E-MAIL CONTENT AND ANY LINKS OR ATTACHMENTS.
>
>
> [re-adding the list]
>
> On 10.04.19 16:44, Lange Norbert wrote:
> >
> >
> >> -Original Message-
> >> From: Xenomai  On Behalf Of Jan Kiszka
> via
> >> Xenomai
> >> Sent: Mittwoch, 10. April 2019 16:36
> >> To: Norbert Lange ; xenomai@xenomai.org
> >> Subject: Re: (unknown)
> >>
> >> E-MAIL FROM A NON-ANDRITZ SOURCE: AS A SECURITY MEASURE, PLEASE
> >> EXERCISE CAUTION WITH E-MAIL CONTENT AND ANY LINKS OR
> ATTACHMENTS.
> >>
> >>
> >> On 10.04.19 13:14, Norbert Lange via Xenomai wrote:
> >>> V3 of the patchset, corrected many checkstyle issues, simplified
> >>> condvar autoinit.
> >>>
> >>> I did not use ARRAY_SIZE, as that would need another include.
> >>>
> >>
> >> All applied now. Patch 1 was not cleanly based on next, though. I think 
> >> some
> >> local style cleanup was missing.
> >
> > I based all patches on master, thought this is the primary development 
> > branch?
> >
>
> Line 566 in lib/cobalt/mutex.c had a trailing tab, your patch context did not,
> and that made the application fail. Maybe that was removed while transporting
> the patch into your mail client - better use git send-email in that case.

I use git send-email, you would not be happy if I sent patches over our IT 
Server
(one or two examples should reside somewhere in the ML) =).

I did use git-format-patch with --ignore-space-at-eol, maybe that’s the reason.

I know there are a few holdouts, but since you got a gitlab server and ci 
running already,
merge-requests could do all those style checks and test for build-failures 
without taking
any time of the maintainers and shorter feedback cycles for the contributors.
My IT is rather hostile to anything email based.

Norbert



This message and any attachments are solely for the use of the intended 
recipients. They may contain privileged and/or confidential information or 
other information protected from disclosure. If you are not an intended 
recipient, you are hereby notified that you received this email in error and 
that any review, dissemination, distribution or copying of this email and any 
attachment is strictly prohibited. If you have received this email in error, 
please contact the sender and delete the message and any attachment from your 
system.

ANDRITZ HYDRO GmbH


Rechtsform/ Legal form: Gesellschaft mit beschränkter Haftung / Corporation

Firmensitz/ Registered seat: Wien

Firmenbuchgericht/ Court of registry: Handelsgericht Wien

Firmenbuchnummer/ Company registration: FN 61833 g

DVR: 0605077

UID-Nr.: ATU14756806


Thank You



[PATCH 1/1] add .clang-format configuration.

2019-04-10 Thread Norbert Lange via Xenomai
nabbed verbatim from the Linux kernel.

Signed-off-by: Norbert Lange 
---
 .clang-format | 469 ++
 1 file changed, 469 insertions(+)
 create mode 100755 .clang-format

diff --git a/.clang-format b/.clang-format
new file mode 100755
index 0..f49620f50
--- /dev/null
+++ b/.clang-format
@@ -0,0 +1,469 @@
+# SPDX-License-Identifier: GPL-2.0
+#
+# clang-format configuration file. Intended for clang-format >= 4.
+#
+# For more information, see:
+#
+#   Documentation/process/clang-format.rst
+#   https://clang.llvm.org/docs/ClangFormat.html
+#   https://clang.llvm.org/docs/ClangFormatStyleOptions.html
+#
+---
+AccessModifierOffset: -4
+AlignAfterOpenBracket: Align
+AlignConsecutiveAssignments: false
+AlignConsecutiveDeclarations: false
+#AlignEscapedNewlines: Left # Unknown to clang-format-4.0
+AlignOperands: true
+AlignTrailingComments: false
+AllowAllParametersOfDeclarationOnNextLine: false
+AllowShortBlocksOnASingleLine: false
+AllowShortCaseLabelsOnASingleLine: false
+AllowShortFunctionsOnASingleLine: None
+AllowShortIfStatementsOnASingleLine: false
+AllowShortLoopsOnASingleLine: false
+AlwaysBreakAfterDefinitionReturnType: None
+AlwaysBreakAfterReturnType: None
+AlwaysBreakBeforeMultilineStrings: false
+AlwaysBreakTemplateDeclarations: false
+BinPackArguments: true
+BinPackParameters: true
+BraceWrapping:
+  AfterClass: false
+  AfterControlStatement: false
+  AfterEnum: false
+  AfterFunction: true
+  AfterNamespace: true
+  AfterObjCDeclaration: false
+  AfterStruct: false
+  AfterUnion: false
+  #AfterExternBlock: false # Unknown to clang-format-5.0
+  BeforeCatch: false
+  BeforeElse: false
+  IndentBraces: false
+  #SplitEmptyFunction: true # Unknown to clang-format-4.0
+  #SplitEmptyRecord: true # Unknown to clang-format-4.0
+  #SplitEmptyNamespace: true # Unknown to clang-format-4.0
+BreakBeforeBinaryOperators: None
+BreakBeforeBraces: Custom
+#BreakBeforeInheritanceComma: false # Unknown to clang-format-4.0
+BreakBeforeTernaryOperators: false
+BreakConstructorInitializersBeforeComma: false
+#BreakConstructorInitializers: BeforeComma # Unknown to clang-format-4.0
+BreakAfterJavaFieldAnnotations: false
+BreakStringLiterals: false
+ColumnLimit: 80
+CommentPragmas: '^ IWYU pragma:'
+#CompactNamespaces: false # Unknown to clang-format-4.0
+ConstructorInitializerAllOnOneLineOrOnePerLine: false
+ConstructorInitializerIndentWidth: 8
+ContinuationIndentWidth: 8
+Cpp11BracedListStyle: false
+DerivePointerAlignment: false
+DisableFormat: false
+ExperimentalAutoDetectBinPacking: false
+#FixNamespaceComments: false # Unknown to clang-format-4.0
+
+# Taken from:
+#   git grep -h '^#define [^[:space:]]*for_each[^[:space:]]*(' include/ \
+#   | sed "s,^#define \([^[:space:]]*for_each[^[:space:]]*\)(.*$,  - '\1'," \
+#   | sort | uniq
+ForEachMacros:
+  - 'apei_estatus_for_each_section'
+  - 'ata_for_each_dev'
+  - 'ata_for_each_link'
+  - '__ata_qc_for_each'
+  - 'ata_qc_for_each'
+  - 'ata_qc_for_each_raw'
+  - 'ata_qc_for_each_with_internal'
+  - 'ax25_for_each'
+  - 'ax25_uid_for_each'
+  - 'bio_for_each_integrity_vec'
+  - '__bio_for_each_segment'
+  - 'bio_for_each_segment'
+  - 'bio_for_each_segment_all'
+  - 'bio_list_for_each'
+  - 'bip_for_each_vec'
+  - 'blkg_for_each_descendant_post'
+  - 'blkg_for_each_descendant_pre'
+  - 'blk_queue_for_each_rl'
+  - 'bond_for_each_slave'
+  - 'bond_for_each_slave_rcu'
+  - 'bpf_for_each_spilled_reg'
+  - 'btree_for_each_safe128'
+  - 'btree_for_each_safe32'
+  - 'btree_for_each_safe64'
+  - 'btree_for_each_safel'
+  - 'card_for_each_dev'
+  - 'cgroup_taskset_for_each'
+  - 'cgroup_taskset_for_each_leader'
+  - 'cpufreq_for_each_entry'
+  - 'cpufreq_for_each_entry_idx'
+  - 'cpufreq_for_each_valid_entry'
+  - 'cpufreq_for_each_valid_entry_idx'
+  - 'css_for_each_child'
+  - 'css_for_each_descendant_post'
+  - 'css_for_each_descendant_pre'
+  - 'device_for_each_child_node'
+  - 'drm_atomic_crtc_for_each_plane'
+  - 'drm_atomic_crtc_state_for_each_plane'
+  - 'drm_atomic_crtc_state_for_each_plane_state'
+  - 'drm_atomic_for_each_plane_damage'
+  - 'drm_connector_for_each_possible_encoder'
+  - 'drm_for_each_connector_iter'
+  - 'drm_for_each_crtc'
+  - 'drm_for_each_encoder'
+  - 'drm_for_each_encoder_mask'
+  - 'drm_for_each_fb'
+  - 'drm_for_each_legacy_plane'
+  - 'drm_for_each_plane'
+  - 'drm_for_each_plane_mask'
+  - 'drm_mm_for_each_hole'
+  - 'drm_mm_for_each_node'
+  - 'drm_mm_for_each_node_in_range'
+  - 'drm_mm_for_each_node_safe'
+  - 'for_each_active_drhd_unit'
+  - 'for_each_active_iommu'
+  - 'for_each_available_child_of_node'
+  - 'for_each_bio'
+  - 'for_each_board_func_rsrc'
+  - 'for_each_bvec'
+  - 'for_each_card_components'
+  - 'for_each_card_links'
+  - 'for_each_card_links_safe'
+  - 'for_each_card_prelinks'
+  - 'for_each_card_rtds'
+  - 'for_each_card_rtds_safe'
+  - 'for_each_cgroup_storage_type'
+  - 'for_each_child_of_node'
+  - 'for_each_clear_bit'
+  - 'for_each_clear_bit_from'
+  - 'fo

Re: (unknown)

2019-04-10 Thread Jan Kiszka via Xenomai

On 10.04.19 17:02, Lange Norbert wrote:




-Original Message-
From: Jan Kiszka 
Sent: Mittwoch, 10. April 2019 16:48
To: Lange Norbert ; Xenomai

Subject: Re: (unknown)

E-MAIL FROM A NON-ANDRITZ SOURCE: AS A SECURITY MEASURE, PLEASE
EXERCISE CAUTION WITH E-MAIL CONTENT AND ANY LINKS OR ATTACHMENTS.


[re-adding the list]

On 10.04.19 16:44, Lange Norbert wrote:




-Original Message-
From: Xenomai  On Behalf Of Jan Kiszka

via

Xenomai
Sent: Mittwoch, 10. April 2019 16:36
To: Norbert Lange ; xenomai@xenomai.org
Subject: Re: (unknown)

E-MAIL FROM A NON-ANDRITZ SOURCE: AS A SECURITY MEASURE, PLEASE
EXERCISE CAUTION WITH E-MAIL CONTENT AND ANY LINKS OR

ATTACHMENTS.



On 10.04.19 13:14, Norbert Lange via Xenomai wrote:

V3 of the patchset, corrected many checkstyle issues, simplified
condvar autoinit.

I did not use ARRAY_SIZE, as that would need another include.



All applied now. Patch 1 was not cleanly based on next, though. I think some
local style cleanup was missing.


I based all patches on master, thought this is the primary development branch?



Line 566 in lib/cobalt/mutex.c had a trailing tab, your patch context did not,
and that made the application fail. Maybe that was removed while transporting
the patch into your mail client - better use git send-email in that case.


I use git send-email, you would not be happy if I sent patches over our IT 
Server
(one or two examples should reside somewhere in the ML) =).


Yeah, I fully understand.



I did use git-format-patch with --ignore-space-at-eol, maybe that’s the reason.


I'm pretty sure that was it. OK - one off.



I know there are a few holdouts, but since you got a gitlab server and ci 
running already,
merge-requests could do all those style checks and test for build-failures 
without taking
any time of the maintainers and shorter feedback cycles for the contributors.
My IT is rather hostile to anything email based.


Unfortunately, also with gitlab, the working mode decision remains a binary one: 
If we start allowing MRs and do review on that platform, we need to migrate 
everything over. There is no integration that allows to mirror one feed into the 
other to avoid community split.


I do quite a few gitlab-based reviews as well, for internal stuff. It's making 
some things easier and others more complicated for me. Tracking the history of 
patch series can be easier. However, reviewing larger series requires large 
amounts of mouse clicks, and you easily lose overview. At least, gitlab is not 
as broken as github (github still reorders patches according to dates - ouch). 
And even in times of CI, and eventually also continuous testing, review remains 
a manual (visual) task.


Jan

--
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux



Re: kvm fpu warning on 4.14.89

2019-04-10 Thread cagnulein via Xenomai
After 3 days of test (latency + windows 10 with cpu-z and stress test) I
reached rare peaks of 130 us.
For me it's OK but I think there is a small "regression" against the 4.9
Do you need any other test?
R.

Il lun 8 apr 2019, 12:13 Jan Kiszka  ha scritto:

> On 08.04.19 11:56, cagnulein wrote:
> > Wow! It works flawless! Latency is just a little higher than 4.9.146 (72
> VS 67)
> > but it's acceptable for me.
> > Now I started a 3 days test. I will let you know.
>
> That's good news!
>
> Let's see if the latency difference is still relevant after measuring
> longer...
>
> Jan
>
> > Thanks!
> > Roberto
> >
> > Il ven 5 apr 2019, 20:31 cagnulein  > > ha scritto:
> >
> > Thank you, on Monday morning I will fire it up! :)
> > R.
> >
> > Il ven 5 apr 2019, 20:29 Jan Kiszka  > > ha scritto:
> >
> > On 05.04.19 15:27, Jan Kiszka wrote:
> >  > On 05.04.19 11:42, Jan Kiszka wrote:
> >  >> On 05.04.19 10:44, cagnulein wrote:
> >  >>> Hi, yes I double checked the patch and it's applied
> correctly.
> >  >>> Here you can find my config.
> >  >>>
> >  >>> CONFIG_DEBUG_STACKOVERFLOW is disabled.
> >  >>>
> >  >>> I can't get the uart on this system, is there any other way
> to
> > catch log in
> >  >>> this scenario?
> >  >>
> >  >> UART is mandatory for debugging such crashes. Use a PCI
> extension
> > card if your
> >  >> board has no UART connector anymore.
> >  >>
> >  >> Well, you may try to lift Xenomai with KVM inside a KVM VM
> and catch
> > the UART
> >  >> output of the first level VM. This is how I'm debugging.
> >  >>
> >  >>>
> >  >>> Why should I test the 4.4.y? 4.9.146 works fine on the same
> system
> > (with the
> >  >>> same guest). Did I miss something?
> >  >>
> >  >> Well, 4.9 would be as broken as 4.4 currently is. But 4.4 is
> > supported, 4.9 is
> >  >> discontinued by now. In any case, this indicates we have
> another
> > difference
> >  >> caused by changed in 4.14 (and before).
> >  >>
> >  >> I'll see if I can reproduce by booting Win10 in my nested
> setup.
> >  >>
> >  >
> >  > Already running the UEFI BIOS triggers something, at least on
> 4.4.
> > Let's see...
> >  >
> >
> > As you will be able to see from the commits, there were a number
> of
> > further issues:
> >
> > https://gitlab.denx.de/Xenomai/ipipe-x86/commits/wip/kvm-4.14
> >
> > With that, I'm able to start Win10 on the same core as the
> latency test.
> > But
> > only in my virtual setup (nested kvm) which may mean that real
> hw could
> > expose
> > further issue or latency problems. Please test.
> >
> > Jan
> >
> > --
> > Siemens AG, Corporate Technology, CT RDA IOT SES-DE
> > Corporate Competence Center Embedded Linux
> >
>
> --
> Siemens AG, Corporate Technology, CT RDA IOT SES-DE
> Corporate Competence Center Embedded Linux
>


Re: kvm fpu warning on 4.14.89

2019-04-10 Thread Jan Kiszka via Xenomai

On 10.04.19 21:26, cagnulein via Xenomai wrote:

After 3 days of test (latency + windows 10 with cpu-z and stress test) I
reached rare peaks of 130 us.
For me it's OK but I think there is a small "regression" against the 4.9
Do you need any other test?


What is the CPU / SoC here? Are we talking about some Atom or rather some Xeon?

If you want us to understand that peak, and if it was just less likely on 4.9,
we would need an ipipe trace from that event. The latency test can trigger a
freeze. We likely needs around 1000 back_trace_points for that.

BTW, as mixing virtualization workload with RT won't make both faster and may
have bad side effects, also on both, isolating them on separate cores should be
preferred whenever possible.

Jan



Re: kvm fpu warning on 4.14.89

2019-04-10 Thread cagnulein via Xenomai
It's a dual core 8th Gen Intel atom.
In the future I will use a quad core atom and probably I will isolate a
core.
I will investigate on ipipe traces. I will let you know, but for me it's OK
anyway.

Il mer 10 apr 2019, 21:36 Jan Kiszka  ha scritto:

> On 10.04.19 21:26, cagnulein via Xenomai wrote:
> > After 3 days of test (latency + windows 10 with cpu-z and stress test) I
> > reached rare peaks of 130 us.
> > For me it's OK but I think there is a small "regression" against the 4.9
> > Do you need any other test?
>
> What is the CPU / SoC here? Are we talking about some Atom or rather some
> Xeon?
>
> If you want us to understand that peak, and if it was just less likely on
> 4.9,
> we would need an ipipe trace from that event. The latency test can trigger
> a
> freeze. We likely needs around 1000 back_trace_points for that.
>
> BTW, as mixing virtualization workload with RT won't make both faster and
> may
> have bad side effects, also on both, isolating them on separate cores
> should be
> preferred whenever possible.
>
> Jan
>