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 inject

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

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

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 --- lib/copperplate/heapobj

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

[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

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

[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

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

[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 +- lib/copperplate/heapobj

[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 --- lib/cobalt

[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

[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

[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 --- lib/cobalt

[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

[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 --- lib/cobalt

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

Re: improve and provide a header for bootstrapping

Am Fr., 26. Okt. 2018 um 15:48 Uhr schrieb Jan Kiszka : > > On 23.10.18 16:16, Norbert Lange wrote: > > Hello, > > > > the following patches allow a variety of options additional > > to the linker magic involved for hijacking the aplications main > > f

[PATCH 2/2] add a header to create flexible bootstrap code

be created, that will be needed for the ld wrapping trick Signed-off-by: Norbert Lange --- include/xenomai/Makefile.am | 7 +- include/xenomai/bootstrap-template.h | 274 +++ include/xenomai/init.h | 2 + lib/boilerplate/init/Makefile.am | 3

improve and provide a header for bootstrapping

Hello, the following patches allow a variety of options additional to the linker magic involved for hijacking the aplications main function. the original method will still continue to work, differences are * the code dealing with retrieving the commandline arguments is moved into

[PATCH 1/2] separate bootstrap code to get commandline, move it into library

to allow fallbacks, define a macro to indicate the function exists in the library Signed-off-by: Norbert Lange --- include/xenomai/init.h | 4 +++ lib/boilerplate/init/bootstrap.c | 48 - lib/boilerplate/setup.c | 62

[Xenomai] [PATCH] cobalt: fcntl uses void* instead of int

this is consistent with glibc internals, and fixes truncation when passing 64bit pointers --- lib/cobalt/rtdm.c | 4 ++-- lib/cobalt/wrappers.c | 4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/lib/cobalt/rtdm.c b/lib/cobalt/rtdm.c index 6b8898e70..a01752cdd 100644 ---

[Xenomai] [PATCH] add missing headers and casts, prefer POSIX definitions

silences some compiler warnings Signed-off-by: Norbert Lange <norbert.la...@andritz.com> --- demo/posix/cobalt/gpiopwm.c | 4 ++-- testsuite/smokey/posix-select/posix-select.c | 3 +++ 2 files changed, 5 insertions(+), 2 deletions(-) diff --git a/demo/posix/cobalt/gpiop

[Xenomai] [PATCH] fix one out-of-bounds access

Signed-off-by: Norbert Lange <norbert.la...@andritz.com> --- testsuite/smokey/net_common/smokey_net_server.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/testsuite/smokey/net_common/smokey_net_server.c b/testsuite/smokey/net_common/smokey_net_server.c index a0e

[Xenomai] [PATCH 1/3] add an flexible bootstrap template header

on precompiled objects or linker wrapping magic. Signed-off-by: Norbert Lange <norbert.la...@andritz.com> --- include/xenomai/Makefile.am | 7 +- include/xenomai/bootstrap-template.h | 270 +++ include/xenomai/init.h | 2 + lib/boilerplate/init/Makef

[Xenomai] [PATCH 3/3] provide an extended xenomai_init function

This function is a single entrypoint for both shared libraries and executables. Futher it allows passing flags as additional argument. Signed-off-by: Norbert Lange <norbert.la...@andritz.com> --- include/xenomai/bootstrap-template.h | 19 + include/xenomai/init.h

[Xenomai] [PATCH] fix one out-of-bounds access

Signed-off-by: Norbert Lange <norbert.la...@andritz.com> --- testsuite/smokey/net_common/smokey_net_server.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/testsuite/smokey/net_common/smokey_net_server.c b/testsuite/smokey/net_common/smokey_net_server.c index a0e

[Xenomai] [PATCH] add missing headers and casts, prefer POSIX definitions

see http://man7.org/linux/man-pages/man2/bind.2.html and http://man7.org/linux/man-pages/man2/open.2.html and http://man7.org/linux/man-pages/man7/sigevent.7.html Signed-off-by: Norbert Lange <norbert.la...@andritz.com> --- demo/posix/cobalt/gpiopwm.c | 4 ++-- testsuite/

Re: [Xenomai] [RFC] RTnet, Analogy and the elephant in the room

Hi, not really happy to hear that, but this was already my impression. There is alot of knowledge of kernel, hardware and bootloader knowledge necessary to be able to maintain the ipipe patch, as newcomer to most of these I am just helpless. Unless someone is dedicated to that, there is not

Re: [Xenomai] Won`t build on new Debian Stable

Sorry, wrong file attached. 2017-10-13 13:36 GMT+02:00 Norbert Lange <nolang...@gmail.com>: > I works, because collect2 (the "compiler driver", which documents the > -r option) now knows about the -r flag, using -Wl,-[U]r would mean the > flags aren't even looked

Re: [Xenomai] Won`t build on new Debian Stable

ght have some subtle differences to before, got some testcase where lacking the -Ur flag made a difference? 2017-10-13 12:26 GMT+02:00 Henning Schild <henning.sch...@siemens.com>: > Am Fri, 13 Oct 2017 11:37:30 +0200 > schrieb Norbert Lange <nolang...@gmail.com>: > >>

Re: [Xenomai] Won`t build on new Debian Stable

02:00 Henning Schild <henning.sch...@siemens.com>: > That looks good to me. > > Henning > > Am Fri, 13 Oct 2017 10:38:26 +0200 > schrieb Norbert Lange <nolang...@gmail.com>: > >> Second attempt at fixing it, you could surely make this more complex >> using a

Re: [Xenomai] Won`t build on new Debian Stable

, Norbert 2017-10-13 9:40 GMT+02:00 Norbert Lange <nolang...@gmail.com>: > Ok I just realized there is a "-Ur" option, aside from "-U -r". > > You get alot otherwise undocumented flags with "gcc --help -v" BTW > > 2017-10-13 9:13 GMT+02:00 Nor

Re: [Xenomai] Won`t build on new Debian Stable

Ok I just realized there is a "-Ur" option, aside from "-U -r". You get alot otherwise undocumented flags with "gcc --help -v" BTW 2017-10-13 9:13 GMT+02:00 Norbert Lange <nolang...@gmail.com>: > Hello, > > I tracked down the source of information to

Re: [Xenomai] Won`t build on new Debian Stable

enomai. > > Henning > > Am Tue, 10 Oct 2017 16:38:50 +0200 > schrieb Norbert Lange <nolang...@gmail.com>: > >> Some highly trivial fix attached! >> Its strange that this flag is not documented in the manual (I found >> out abaout this fix from https://l

Re: [Xenomai] Won`t build on new Debian Stable

Some highly trivial fix attached! Its strange that this flag is not documented in the manual (I found out abaout this fix from https://launchpad.net/ubuntu/+source/flint) Norbert Lange 2017-08-10 11:49 GMT+02:00 Henning Schild <henning.sch...@siemens.com>: > Hi Norbert, > >

[Xenomai] Won`t build on new Debian Stable

Hello, Building the xenomai package won`t work because debian now defaults to using pie, and the linker will complain with "ld: -r and -pie may not be used together" A workaround for now is to add the flags manually: ../xenomai-3.0.5/configure LDFLAGS=-no-pie CFLAGS="-fno-PIE -fno-pie -no-pie"

Re: [Xenomai] latency test and mercury

. It was attempt to get a quick peek at Xenomai without building a system for it. Thanks, Norbert 2017-02-22 9:59 GMT+01:00 Philippe Gerum <r...@xenomai.org>: > On 02/21/2017 07:37 PM, Norbert Lange wrote: >> Hi, >> >> I got some really big variations on the latency te

[Xenomai] latency test and mercury

Hi, I got some really big variations on the latency test (up to 4ms), but I am not exactly sure if this supposed the realtime portion. I am unable to run kernel or irq tests. For a user thread, this is probably like expected since this is a full debian desktop with RT kernel. If I understood

Re: [Xenomai] RtNet and Interrupts

2017-02-17 12:47 GMT+01:00 Mariusz Janiak <mariuszjan...@wp.pl>: > Dnia Piątek, 17 Lutego 2017 12:19 Norbert Lange <nolang...@gmail.com> > napisał(a) > *snip* > > Maybe author of the RTnet stack can give better answer, but in my opinion, in > the case of the

Re: [Xenomai] RtNet and Interrupts

2017-02-17 11:45 GMT+01:00 Mariusz Janiak <mariuszjan...@wp.pl>: > Dnia Piątek, 17 Lutego 2017 11:18 Norbert Lange <nolang...@gmail.com> > napisał(a) >> Hello, >> >> I wonder if the Rtnet Stack is driven at packet level, ie. if after >> every o

[Xenomai] RtNet and Interrupts

Hello, I wonder if the Rtnet Stack is driven at packet level, ie. if after every one received packet( or even buffer) an IRQ is received. I worked on a Project where a similar Problem with Ethernet communication had to be solved, and I just queued up enough receive buffers and just picked up