Re: [lttng-dev] LTTng - Xenomai : different results between timestamp-lttng and rt_time_read()

Am Fr., 21. Mai 2021 um 12:13 Uhr schrieb MONTET Julien : > > Hello Mathieu, Norbert and Jan, > > Thank you for all of your explainations and the overview of the system. > No I didn't change the ipipe patch for the vDSO, I may try this. > If I have correctly understood, this patch prevents Cobalt

Re: [lttng-dev] LTTng - Xenomai : different results between timestamp-lttng and rt_time_read()

Am Do., 20. Mai 2021 um 17:09 Uhr schrieb Mathieu Desnoyers : > > - On May 20, 2021, at 9:56 AM, Mathieu Desnoyers > mathieu.desnoy...@efficios.com wrote: > > > - On May 20, 2021, at 9:54 AM, lttng-dev lttng-...@lists.lttng.org > > wrote: > > > >> - On May 20, 2021, at 5:11 AM,

Re: [PATCH v2] cobalt: allow to compile without __USE_LARGEFILE64

Well, I dont think 1-2 lines of a preprocessor checks count as some kind of intellectual work. I wouldn't think that way if I take some pretty much known math formula from wikipedia. Norbert Am So., 19. Apr. 2020 um 11:22 Uhr schrieb Jan Kiszka : > > On 17.04.20 10:35, Norbert Lange via X

Re: [PATCH] cobalt: allow to compile without __USE_LARGEFILE64

orbert Lange via Xenomai wrote: > > A header uses the off64_t which is only conditionally available, > > causing compile failures. > > The macro might be necessary to compile cobalt libraries, > > but should not be needed for software depending on them. > &

[PATCH v2] cobalt: allow to compile without __USE_LARGEFILE64

A header uses the off64_t which is only conditionally available, causing compile failures. The macro might be necessary to compile cobalt libraries, but should not be needed for software depending on them. Signed-off-by: Norbert Lange --- include/cobalt/sys/mman.h | 2 ++ 1 file changed, 2

[PATCH] cobalt: allow to compile without __USE_LARGEFILE64

A header uses the off64_t which is only conditionally available, causing compile failures. The macro might be necessary to compile cobalt libraries, but should not be needed for software depending on them. Signed-off-by: Norbert Lange --- include/cobalt/sys/mman.h | 2 ++ 1 file changed, 2

Re: [lttng-dev] Using lttng-ust with xenomai

> >> liburcu has configure options allow forcing the usage of this syscall > >> but not disabling it, which likely is necessary for Xenomai. > > > > I suspect what you'd need there is a way to allow a process to tell > > liburcu-bp (or liburcu) to always use the fall-back

Re: [lttng-dev] Using lttng-ust with xenomai

> >> >> > Another thing to make sure is to have a glibc and Linux kernel which > >> >> > perform > >> >> > clock_gettime() as vDSO for the monotonic clock, because you don't > >> >> > want a > >> >> > system call there. If that does not work for you, you can > >> >> > alternatively > >> >> >

Re: [lttng-dev] Using lttng-ust with xenomai

Am Fr., 22. Nov. 2019 um 20:03 Uhr schrieb Mathieu Desnoyers : > > - On Nov 22, 2019, at 12:55 PM, Norbert Lange nolang...@gmail.com wrote: > > >> > >> LTTng-UST prepares the ring buffers from lttng-ust's "listener" thread, > >> which is injected into the process by a lttng-ust constructor. >

Re: [lttng-dev] Using lttng-ust with xenomai

Am Fr., 22. Nov. 2019 um 18:52 Uhr schrieb Jan Kiszka : > > On 22.11.19 18:44, Norbert Lange wrote: > > Am Fr., 22. Nov. 2019 um 16:52 Uhr schrieb Jan Kiszka > > : > >> > >> On 22.11.19 16:42, Mathieu Desnoyers wrote: > >>> - On Nov 22, 2019, at 4:14 AM, Norbert Lange nolang...@gmail.com >

Re: [lttng-dev] Using lttng-ust with xenomai

> > LTTng-UST prepares the ring buffers from lttng-ust's "listener" thread, > which is injected into the process by a lttng-ust constructor. > > What you will care about is how the tracepoint call-site (within a Xenomai > thread) interacts with the ring buffers. > > The "default" setup for

Re: [lttng-dev] Using lttng-ust with xenomai

Am Fr., 22. Nov. 2019 um 16:52 Uhr schrieb Jan Kiszka : > > On 22.11.19 16:42, Mathieu Desnoyers wrote: > > - On Nov 22, 2019, at 4:14 AM, Norbert Lange nolang...@gmail.com wrote: > > > >> Hello, > >> > >> I already started a thread over at xenomai.org [1], but I guess its > >> more efficient

running xenomai through scan-build or: some 100 issues with static code analysis

Hello, I did run some static analysis tools over xenomai 3.1rc2 userspace libraries, and there seems to be alot of real issues. The tools are clangs builtin statical analysis and clang-tidy, naturally there is some overlap in the reports. clang-tidy would need to be configured to fit Xenomai's

[PATCH] cobalt: remove call to sigprocmask

sigprocmask should not be used in multithreaded applications, doing so is "unspecified". Signed-off-by: Norbert Lange --- lib/cobalt/printf.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lib/cobalt/printf.c b/lib/cobalt/printf.c index 7426f2bda..80db9516a 100644 ---

[PATCH 2/2] lib/cobalt: set name for printf thread to help debugging

Signed-off-by: Norbert Lange --- lib/cobalt/printf.c | 1 + 1 file changed, 1 insertion(+) diff --git a/lib/cobalt/printf.c b/lib/cobalt/printf.c index 33ff7f9ac..7426f2bda 100644 --- a/lib/cobalt/printf.c +++ b/lib/cobalt/printf.c @@ -648,6 +648,7 @@ static void spawn_printer_thread(void)

[PATCH 1/2] lib/copperplate: remove wrapped heap function

this will remove the dependency to libmodechk, the original intent was to allow RT threads call non-RT functions. As the threads require to have weak scheduling policy, there is no need to avoid checks (which arent active in that policy). Signed-off-by: Norbert Lange ---

[PATCH 2/2] xeno-config: dont unconditionally link libmodechk with cobalt

Allow to build without linking to libmodechk.so. Signed-off-by: Norbert Lange --- scripts/xeno-config-cobalt.in | 8 ++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/scripts/xeno-config-cobalt.in b/scripts/xeno-config-cobalt.in index ae313d389..87d54fbf8 100644 ---

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

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

[no subject]

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

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

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

[no subject]

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

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

[PATCH v2 2/2] Simplify xenomai_count_leading_zeros

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

[PATCH v2 1/2] Rename __ctz to xenomai_count_trailing_zeros

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 +-

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

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

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

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

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

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 ---

[no subject]

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

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

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

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

[PATCH 2/2] Simplify xenomai_count_leading_zeros

Covers now all standard integer types, no need for corner cases. Signed-off-by: Norbert Lange --- include/boilerplate/compiler.h | 27 +++ 1 file changed, 7 insertions(+), 20 deletions(-) diff --git a/include/boilerplate/compiler.h b/include/boilerplate/compiler.h index

Rework __ctz and __clz macros

Those are commonly used in Frameworks (eg libc++), This series renamed __ctz and replaces the __clz with something simpler that could be evaluated in constant contexts aswell (and doesnt use GCC statement expressions). Ideally though these would be moved out of the public header into something

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

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 be9f6ed80..125981d40 100644 --- a/lib/cobalt/mutex.c +++ b/lib/cobalt/mutex.c @@ -49,8 +49,12 @@ * By default, Cobalt

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

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 | 14 +++ testsuite/smokey/posix-mutex/posix-mutex.c | 47 ++ 2 files

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

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 92eb230ff..cdbd512ae 100644 --- a/lib/cobalt/cond.c +++ b/lib/cobalt/cond.c @@ -47,9 +47,13 @@ * several processes (it

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

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 | 93

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

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 explicitely initialised, so no change needed there Signed-off-by: Norbert Lange ---

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

add a few testcases whete dstroy is called as first function, and test failure if the state is a non-standard initializater. Signed-off-by: Norbert Lange --- testsuite/smokey/posix-cond/posix-cond.c | 14 testsuite/smokey/posix-mutex/posix-mutex.c | 93 -- 2 files

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

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 92eb230ff..cdbd512ae 100644 --- a/lib/cobalt/cond.c +++ b/lib/cobalt/cond.c @@ -47,9 +47,13 @@ * several processes (it

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

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 be9f6ed80..125981d40 100644 --- a/lib/cobalt/mutex.c +++ b/lib/cobalt/mutex.c @@ -49,8 +49,12 @@ * By default, Cobalt

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

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 | 93

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

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 explicitely initialised, so no change needed there Signed-off-by: Norbert Lange ---

Re: Fwd: Debugging system freeze, SIGXCPU

> Sure - make sense - IMO just knowing which calls are potentially problematic is > the difficult part here. I expect I will just continue to stumble through them > and learn more as I go. I wrote some checkers that should be able to catch those calls (had pretty much the same issue, legacy