Gilles Chanteperdrix wrote: > Jan Kiszka wrote: > > > Is there no way to make this code easier to port for example by using > > > native or posix services for timings measurement and by abstracting the > > > non portable part and moving them to include/asm-i386 ? > > > > This tool is intentionally left Xenomai-free. You can put it on any x86 > > box around (and I assume that there is almost always some...) and run > > the test. Thus, no need for a second RT-patched system. > > > > Anyway, suggestions or patches to add a porting layer are welcome. The > > following points need to be addressed: time measuring, irq protection, > > hardware access. I just wonder if this is worth the effort. > > I do not understand: it appears to me that Xenomai trunk does not > compile on other architectures than x86 when applying the IRQ latency > benchmark patch. So, something needs to be done. It may be the enabling > of an automake conditional in configure.in when compiling for x86. >
See the patch: Index: xenomai/src/testsuite/irqbench/Makefile.am =================================================================== --- /dev/null +++ xenomai/src/testsuite/irqbench/Makefile.am @@ -0,0 +1,47 @@ +testdir = $(prefix)/testsuite/irqbench + +test_PROGRAMS = irqloop + +ifeq ($(XENO_TARGET_ARCH),i386) +test_PROGRAMS += irqbench +endif I just realised that some hint in the documentation that irqbench can easily be compiled outside Xenomai is required. > > > > > > > > Also note that calling printf from a signal handler risk deadlocking if > > > the signal handler get called on the return path of the write call that > > > take place in the middle of a printf call on the main thread. > > > > > > > Ok, then we also need a fix for the latency test (this is where I > > grabbed that pattern from). Is there a high risk that this locks up? I > > wonder why I never observed or heard of problems with latency. > > The latency test used to deadlock, that is why the summary printed on > signal is printed on stderr. Unfortunately, there seem to be one display > left on stdout, so it should still deadlock. The reason why we never see > the deadlock is (perhaps) that the continuous intermediate results are > printed on the context of the "display" thread, whereas the termination > signals are preferably delivered by the kernel to the "main" thread, > that only calls pause. Which makes the use of stderr in signals handlers > pointless. > > Anyway, since your program is frequently using printf on the context of > the main thread, the risk of deadlock is real. > Ok, I'm going to address this. Thanks for the hint! Jan
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
