Re: [Xenomai-core] [PATCH] ipipe-tracer-v5
Jan Kiszka wrote:
--- linux-2.6.14.3/arch/i386/boot/compressed/misc.c.orig 2005-11-24
23:10:21.0 +0100
+++ linux-2.6.14.3/arch/i386/boot/compressed/misc.c 2005-12-28
16:12:43.0 +0100
@@ -15,6 +15,12 @@
#include asm/io.h
#include asm/page.h
+#ifdef CONFIG_IPIPE_TRACE
+void __attribute__ ((no_instrument_function)) mcount(void)
+{
+}
+#endif
+
/*
* gzip declarations
*/
@@ -112,7 +118,7 @@
#define INPLACE_MOVE_ROUTINE 0x1000
#define LOW_BUFFER_START 0x2000
#define LOW_BUFFER_MAX 0x9
-#define HEAP_SIZE 0x3000
+#define HEAP_SIZE 0x4000
static unsigned int low_buffer_end, low_buffer_size;
static int high_loaded =0;
static uch *high_buffer_start /* = (uch *)(((ulg)end) + HEAP_SIZE)*/;
@@ -125,6 +131,7 @@
static void * xquad_portio = NULL;
#endif
+#define ZLIB_INFLATE_NO_INFLATE_LOCK
#include ../../../../lib/inflate.c
With the recent advent of a broken-out latency trace patch for the
standard kernel, it became clear what the last patched line is for:
nothing in this case, it only makes sense as the full
reduce-zlib-stack-hack.patch available from
http://people.redhat.com/mingo/latency-tracing-patches/patches
One only need this add-on patch when running the tracing kernel with 4k
stacks.
Philippe, I think we should not merge this particular line change. In
contrast, the HEAP_SIZE change also appears in the tracer patch itself.
Jan
signature.asc
Description: OpenPGP digital signature
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH] ipipe-tracer-v5
Jan Kiszka wrote:
Jan Kiszka wrote:
--- linux-2.6.14.3/arch/i386/boot/compressed/misc.c.orig2005-11-24
23:10:21.0 +0100
+++ linux-2.6.14.3/arch/i386/boot/compressed/misc.c 2005-12-28
16:12:43.0 +0100
@@ -15,6 +15,12 @@
#include asm/io.h
#include asm/page.h
+#ifdef CONFIG_IPIPE_TRACE
+void __attribute__ ((no_instrument_function)) mcount(void)
+{
+}
+#endif
+
/*
* gzip declarations
*/
@@ -112,7 +118,7 @@
#define INPLACE_MOVE_ROUTINE 0x1000
#define LOW_BUFFER_START 0x2000
#define LOW_BUFFER_MAX 0x9
-#define HEAP_SIZE 0x3000
+#define HEAP_SIZE 0x4000
static unsigned int low_buffer_end, low_buffer_size;
static int high_loaded =0;
static uch *high_buffer_start /* = (uch *)(((ulg)end) + HEAP_SIZE)*/;
@@ -125,6 +131,7 @@
static void * xquad_portio = NULL;
#endif
+#define ZLIB_INFLATE_NO_INFLATE_LOCK
#include ../../../../lib/inflate.c
With the recent advent of a broken-out latency trace patch for the
standard kernel, it became clear what the last patched line is for:
nothing in this case, it only makes sense as the full
reduce-zlib-stack-hack.patch available from
http://people.redhat.com/mingo/latency-tracing-patches/patches
One only need this add-on patch when running the tracing kernel with 4k
stacks.
Philippe, I think we should not merge this particular line change. In
contrast, the HEAP_SIZE change also appears in the tracer patch itself.
Ack.
--
Philippe.
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] 2.4.32 compilation error + old timer example problem
Hannes Mayer wrote: Jan Kiszka wrote: [...] Yea, maybe that periodic timer mode is not compiled in and rt_timer_start fails in your original example. I think it's off by default now. Yeah, got it! Sorry for not supplying error code earlier! In Xeno source: int xnpod_start_timer (u_long nstick, xnisr_t tickhandler) [...] #ifndef CONFIG_XENO_HW_PERIODIC_TIMER if (nstick != XN_APERIODIC_TICK) return -ENODEV; /* No periodic support */ #endif /* CONFIG_XENO_HW_PERIODIC_TIMER */ ..and guess what: I got -ENODEV back on rt_timer_start! In .config I have # CONFIG_XENO_HW_PERIODIC_TIMER is not set So the puzzle is solved! Just one question: what's the reason why the periodic mode is disabled by default ? Because AFAICT, most people would rather use the aperiodic timing mode in usual configurations for a much better accuracy. Since the periodic mode uses the available hw PIT and programs it once (or even some decrementer but without handling the time drift when reprogramming it after each shot), it suffers from cumulated rounding errors of the period. If you look at the jitter results of a trivial periodic loop over a broad timescale, you will see the wakeup time irremediably drift, whilst the average interval between shots remains stable and reasonably accurate. The periodic timer should be used for configurations that only need to enforce delays or timeouts, and not, well, precise timings. Thanks best regards, Hannes. -- Philippe. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH] fixing modprobe hint in libs
Jan Kiszka wrote: Hi, this patches fixes the hint a user sees when trying to start some RT-application without the related core service being available. Might be frustrating for a newbie if the suggested command fails... Applied, thanks. Jan Index: src/skins/uvm/init.c === --- src/skins/uvm/init.c(Revision 304) +++ src/skins/uvm/init.c(Arbeitskopie) @@ -56,7 +56,7 @@ case -ESRCH: fprintf(stderr,Xenomai: UVM skin or CONFIG_XENO_OPT_PERVASIVE disabled.\n); - fprintf(stderr,(modprobe xeno_uvm.ko?)\n); + fprintf(stderr,(modprobe xeno_uvm?)\n); exit(1); default: Index: src/skins/rtai/init.c === --- src/skins/rtai/init.c (Revision 304) +++ src/skins/rtai/init.c (Arbeitskopie) @@ -53,7 +53,7 @@ case -ESRCH: fprintf(stderr,Xenomai: RTAI skin or CONFIG_XENO_OPT_PERVASIVE disabled.\n); - fprintf(stderr,(modprobe xeno_rtai.ko?)\n); + fprintf(stderr,(modprobe xeno_rtai?)\n); exit(1); default: Index: src/skins/posix/init.c === --- src/skins/posix/init.c (Revision 304) +++ src/skins/posix/init.c (Arbeitskopie) @@ -59,7 +59,7 @@ case -ESRCH: fprintf(stderr,Xenomai: POSIX skin or CONFIG_XENO_OPT_PERVASIVE disabled.\n); - fprintf(stderr,(modprobe xeno_posix.ko?)\n); + fprintf(stderr,(modprobe xeno_posix?)\n); exit(1); default: Index: src/skins/native/init.c === --- src/skins/native/init.c (Revision 304) +++ src/skins/native/init.c (Arbeitskopie) @@ -65,7 +65,7 @@ case -ESRCH: fprintf(stderr,Xenomai: native skin or CONFIG_XENO_OPT_PERVASIVE disabled.\n); - fprintf(stderr,(modprobe xeno_native.ko?)\n); + fprintf(stderr,(modprobe xeno_native?)\n); exit(1); default: ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core -- Philippe. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] autostart timer, rt_timer_start/stop
Hi, cant the timer be started by default ? The current state (2.0.1) seems to lead to the following scenario: 1) Every app calls rt_timer_start() 2) If you call rt_timer_stop you can hurt other rt-apps, so dont call it 3) As some apps dont stop the timer, check in 1) if its already running I think most apps do not care in which mode the timer is running if it is already, and just go on, of course you can stop and restart the timer if its a wrong state, but you do not know if you hurt others. Now, as i read in the other thread that the periodic timer support isnt configured by default, why not start the oneshot timer automatic ? Like this, a 'normal' app doesnt need to fiddle with the timer and an app that really cares can still call rt_timer_inquire,_stop,_start. kisda signature.asc Description: OpenPGP digital signature ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] autostart timer, rt_timer_start/stop
Jan Kiszka wrote: Stefan Kisdaroczi wrote: Hi, cant the timer be started by default ? The current state (2.0.1) seems to lead to the following scenario: 1) Every app calls rt_timer_start() 2) If you call rt_timer_stop you can hurt other rt-apps, so dont call it 3) As some apps dont stop the timer, check in 1) if its already running I think most apps do not care in which mode the timer is running if it is already, and just go on, of course you can stop and restart the timer if its a wrong state, but you do not know if you hurt others. Now, as i read in the other thread that the periodic timer support isnt configured by default, why not start the oneshot timer automatic ? Like this, a 'normal' app doesnt need to fiddle with the timer and an app that really cares can still call rt_timer_inquire,_stop,_start. Yea, that's good that someone else brings this topic up again! :) I've been pointing on this several times, but as we did not come to a conclusion how to handle the system timer in a consistent way across all skins, no one (me included...) came up with a fix of this issue so far. Looks like pending, indeed: https://gna.org/bugs/?func=detailitemitem_id=4551 The thing is that most skins start the timer during module init via some parameter (nowadays also as a kernel boot option for compiled-in skins). As far as I remember, only the native and the RTAI compat skin do their own dance - the latter one has to remain compatible, ok, but the former one should be allowed to perform smarter. Ok, to be more concrete: autostarting the one-shot time in the absence of periodic mode is certainly worth considering. For the other cases and as sysfs is no option on 2.4 kernels, what about adding a /proc-exported control mechanism for the timer mode (and period) to either the HAL or the nucleus? Nucleus. Additionally, we could provide some CONFIG_xyz to set the default mode during compile time. Since we can't have more than a single timer setting at any time, a CONFIG switch in the General menu would be ok. In such a case, moving the currently arch-dep CONFIG_XENO_HW_PERIODIC_TIMER to the General config section would make sense too, so that we would have all timer options at the same place (periodic timing can always be emulated using some underlying oneshot hw timer, and all archs are expected to provide at least some form of oneshot timer anyway). Ceterum censeo rt_timer_start/stop esse delendam. ;) Perhaps not, otherwise we would have some trouble crafting tests and benchmarks for instance. But these are indeed relics from the Stone Age we'd better deprecate for normal use. Jan -- Philippe. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] autostart timer, rt_timer_start/stop
Philippe Gerum wrote: Jan Kiszka wrote: Stefan Kisdaroczi wrote: Hi, cant the timer be started by default ? The current state (2.0.1) seems to lead to the following scenario: 1) Every app calls rt_timer_start() 2) If you call rt_timer_stop you can hurt other rt-apps, so dont call it 3) As some apps dont stop the timer, check in 1) if its already running I think most apps do not care in which mode the timer is running if it is already, and just go on, of course you can stop and restart the timer if its a wrong state, but you do not know if you hurt others. Now, as i read in the other thread that the periodic timer support isnt configured by default, why not start the oneshot timer automatic ? Like this, a 'normal' app doesnt need to fiddle with the timer and an app that really cares can still call rt_timer_inquire,_stop,_start. Yea, that's good that someone else brings this topic up again! :) I've been pointing on this several times, but as we did not come to a conclusion how to handle the system timer in a consistent way across all skins, no one (me included...) came up with a fix of this issue so far. Looks like pending, indeed: https://gna.org/bugs/?func=detailitemitem_id=4551 Ha, totally forgot this one - I actually posted it. :) The thing is that most skins start the timer during module init via some parameter (nowadays also as a kernel boot option for compiled-in skins). As far as I remember, only the native and the RTAI compat skin do their own dance - the latter one has to remain compatible, ok, but the former one should be allowed to perform smarter. Ok, to be more concrete: autostarting the one-shot time in the absence of periodic mode is certainly worth considering. For the other cases and as sysfs is no option on 2.4 kernels, what about adding a /proc-exported control mechanism for the timer mode (and period) to either the HAL or the nucleus? Nucleus. Additionally, we could provide some CONFIG_xyz to set the default mode during compile time. Since we can't have more than a single timer setting at any time, a CONFIG switch in the General menu would be ok. In such a case, moving the currently arch-dep CONFIG_XENO_HW_PERIODIC_TIMER to the General config section would make sense too, so that we would have all timer options at the same place (periodic timing can always be emulated using some underlying oneshot hw timer, and all archs are expected to provide at least some form of oneshot timer anyway). Ceterum censeo rt_timer_start/stop esse delendam. ;) Perhaps not, otherwise we would have some trouble crafting tests and benchmarks for instance. But these are indeed relics from the Stone Age we'd better deprecate for normal use. Let's assume we have extended /proc/xenomai/timer by accepting the timer period as input (comparable to tick_hz module paramters of some skins), we could simply tune it at benchmark startup by issuing echo 0 /proc/xenomai/timer, either in the start script or from within the application. BTW, would the /proc/xenomai/timer interface make sense to you? Jan signature.asc Description: OpenPGP digital signature ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] 2.4.32 compilation error + old timer example problem
Philippe Gerum wrote: [...] Just one question: what's the reason why the periodic mode is disabled by default ? Because AFAICT, most people would rather use the aperiodic timing mode in usual configurations for a much better accuracy. Since the periodic mode uses the available hw PIT and programs it once (or even some decrementer but without handling the time drift when reprogramming it after each shot), it suffers from cumulated rounding errors of the period. If you look at the jitter results of a trivial periodic loop over a broad timescale, you will see the wakeup time irremediably drift, whilst the average interval between shots remains stable and reasonably accurate. The periodic timer should be used for configurations that only need to enforce delays or timeouts, and not, well, precise timings. Thanks Philippe! If it's for accuracy, keep it that way! Best regards, Hannes. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] [rt shared irqs] changes on the adeos-ipipe layer v.2
Hi everybody, the recent patches are enclosed here. Mmm I haven't ported it to the recent adeos-ipipe xeno though but I guess it's not a big obstacle for possible design-related comments etc. just to note some main issues... o the ipipe_virtualize_irq() interface now includes an additional param, namely - void *cookie. o ipipe_domain::cpudata::irq_hits has been renamed to irq_pending_hits while irq_hits now stands for the former rthal_realtime_irq::irq_hits. It's incremeneted in ipipe_irq_handle() and ipipe_schedule_irq(), IOW at the places where irqs (normal or virtual) become visible on the adeos radar first time. Another approach would be to increment it in ipipe_sync_stage() right before calling actual isr handlers. This way, accounting (well, it depends what are we going to count though) would be wrong for virq and ipipe_tick_irq handler. er.. I was confused by the fact that sum of all apcs in /proc/xenomai/apc != virq from /proc/xenomai/irq, but ipipe_printk_virq is not listed since it's registered without rthal::apc interface. Ok, should take a look at it closer, i.e. maybe at least rthal_linux_irq can be reworked now. -- Best regards,Dmitry Adamushko ipipe-i386-1.0-10-ext-2.patch Description: Binary data xenomai-2.1-i386-ext-2.patch Description: Binary data ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] 2.4.32 compilation error + old timer example problem
Jan Kiszka wrote: [...] Yea, maybe that periodic timer mode is not compiled in and rt_timer_start fails in your original example. I think it's off by default now. Yeah, got it! Sorry for not supplying error code earlier! In Xeno source: int xnpod_start_timer (u_long nstick, xnisr_t tickhandler) [...] #ifndef CONFIG_XENO_HW_PERIODIC_TIMER if (nstick != XN_APERIODIC_TICK) return -ENODEV; /* No periodic support */ #endif /* CONFIG_XENO_HW_PERIODIC_TIMER */ ..and guess what: I got -ENODEV back on rt_timer_start! In .config I have # CONFIG_XENO_HW_PERIODIC_TIMER is not set So the puzzle is solved! Just one question: what's the reason why the periodic mode is disabled by default ? Thanks best regards, Hannes.
Re: [Xenomai-core] [PATCH] ipipe-tracer-v5
Jan Kiszka wrote:
Jan Kiszka wrote:
--- linux-2.6.14.3/arch/i386/boot/compressed/misc.c.orig2005-11-24
23:10:21.0 +0100
+++ linux-2.6.14.3/arch/i386/boot/compressed/misc.c 2005-12-28
16:12:43.0 +0100
@@ -15,6 +15,12 @@
#include asm/io.h
#include asm/page.h
+#ifdef CONFIG_IPIPE_TRACE
+void __attribute__ ((no_instrument_function)) mcount(void)
+{
+}
+#endif
+
/*
* gzip declarations
*/
@@ -112,7 +118,7 @@
#define INPLACE_MOVE_ROUTINE 0x1000
#define LOW_BUFFER_START 0x2000
#define LOW_BUFFER_MAX 0x9
-#define HEAP_SIZE 0x3000
+#define HEAP_SIZE 0x4000
static unsigned int low_buffer_end, low_buffer_size;
static int high_loaded =0;
static uch *high_buffer_start /* = (uch *)(((ulg)end) + HEAP_SIZE)*/;
@@ -125,6 +131,7 @@
static void * xquad_portio = NULL;
#endif
+#define ZLIB_INFLATE_NO_INFLATE_LOCK
#include ../../../../lib/inflate.c
With the recent advent of a broken-out latency trace patch for the
standard kernel, it became clear what the last patched line is for:
nothing in this case, it only makes sense as the full
reduce-zlib-stack-hack.patch available from
http://people.redhat.com/mingo/latency-tracing-patches/patches
One only need this add-on patch when running the tracing kernel with 4k
stacks.
Philippe, I think we should not merge this particular line change. In
contrast, the HEAP_SIZE change also appears in the tracer patch itself.
Ack.
--
Philippe.
Re: [Xenomai-core] 2.4.32 compilation error + old timer example problem
Hannes Mayer wrote: Jan Kiszka wrote: [...] Yea, maybe that periodic timer mode is not compiled in and rt_timer_start fails in your original example. I think it's off by default now. Yeah, got it! Sorry for not supplying error code earlier! In Xeno source: int xnpod_start_timer (u_long nstick, xnisr_t tickhandler) [...] #ifndef CONFIG_XENO_HW_PERIODIC_TIMER if (nstick != XN_APERIODIC_TICK) return -ENODEV; /* No periodic support */ #endif /* CONFIG_XENO_HW_PERIODIC_TIMER */ ..and guess what: I got -ENODEV back on rt_timer_start! In .config I have # CONFIG_XENO_HW_PERIODIC_TIMER is not set So the puzzle is solved! Just one question: what's the reason why the periodic mode is disabled by default ? Because AFAICT, most people would rather use the aperiodic timing mode in usual configurations for a much better accuracy. Since the periodic mode uses the available hw PIT and programs it once (or even some decrementer but without handling the time drift when reprogramming it after each shot), it suffers from cumulated rounding errors of the period. If you look at the jitter results of a trivial periodic loop over a broad timescale, you will see the wakeup time irremediably drift, whilst the average interval between shots remains stable and reasonably accurate. The periodic timer should be used for configurations that only need to enforce delays or timeouts, and not, well, precise timings. Thanks best regards, Hannes. -- Philippe.
Re: [Xenomai-core] [PATCH] fixing modprobe hint in libs
Jan Kiszka wrote: Hi, this patches fixes the hint a user sees when trying to start some RT-application without the related core service being available. Might be frustrating for a newbie if the suggested command fails... Applied, thanks. Jan Index: src/skins/uvm/init.c === --- src/skins/uvm/init.c(Revision 304) +++ src/skins/uvm/init.c(Arbeitskopie) @@ -56,7 +56,7 @@ case -ESRCH: fprintf(stderr,Xenomai: UVM skin or CONFIG_XENO_OPT_PERVASIVE disabled.\n); - fprintf(stderr,(modprobe xeno_uvm.ko?)\n); + fprintf(stderr,(modprobe xeno_uvm?)\n); exit(1); default: Index: src/skins/rtai/init.c === --- src/skins/rtai/init.c (Revision 304) +++ src/skins/rtai/init.c (Arbeitskopie) @@ -53,7 +53,7 @@ case -ESRCH: fprintf(stderr,Xenomai: RTAI skin or CONFIG_XENO_OPT_PERVASIVE disabled.\n); - fprintf(stderr,(modprobe xeno_rtai.ko?)\n); + fprintf(stderr,(modprobe xeno_rtai?)\n); exit(1); default: Index: src/skins/posix/init.c === --- src/skins/posix/init.c (Revision 304) +++ src/skins/posix/init.c (Arbeitskopie) @@ -59,7 +59,7 @@ case -ESRCH: fprintf(stderr,Xenomai: POSIX skin or CONFIG_XENO_OPT_PERVASIVE disabled.\n); - fprintf(stderr,(modprobe xeno_posix.ko?)\n); + fprintf(stderr,(modprobe xeno_posix?)\n); exit(1); default: Index: src/skins/native/init.c === --- src/skins/native/init.c (Revision 304) +++ src/skins/native/init.c (Arbeitskopie) @@ -65,7 +65,7 @@ case -ESRCH: fprintf(stderr,Xenomai: native skin or CONFIG_XENO_OPT_PERVASIVE disabled.\n); - fprintf(stderr,(modprobe xeno_native.ko?)\n); + fprintf(stderr,(modprobe xeno_native?)\n); exit(1); default: ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core -- Philippe.
[Xenomai-core] autostart timer, rt_timer_start/stop
Hi, cant the timer be started by default ? The current state (2.0.1) seems to lead to the following scenario: 1) Every app calls rt_timer_start() 2) If you call rt_timer_stop you can hurt other rt-apps, so dont call it 3) As some apps dont stop the timer, check in 1) if its already running I think most apps do not care in which mode the timer is running if it is already, and just go on, of course you can stop and restart the timer if its a wrong state, but you do not know if you hurt others. Now, as i read in the other thread that the periodic timer support isnt configured by default, why not start the oneshot timer automatic ? Like this, a 'normal' app doesnt need to fiddle with the timer and an app that really cares can still call rt_timer_inquire,_stop,_start. kisda signature.asc Description: OpenPGP digital signature
Re: [Xenomai-core] autostart timer, rt_timer_start/stop
Stefan Kisdaroczi wrote: Hi, cant the timer be started by default ? The current state (2.0.1) seems to lead to the following scenario: 1) Every app calls rt_timer_start() 2) If you call rt_timer_stop you can hurt other rt-apps, so dont call it 3) As some apps dont stop the timer, check in 1) if its already running I think most apps do not care in which mode the timer is running if it is already, and just go on, of course you can stop and restart the timer if its a wrong state, but you do not know if you hurt others. Now, as i read in the other thread that the periodic timer support isnt configured by default, why not start the oneshot timer automatic ? Like this, a 'normal' app doesnt need to fiddle with the timer and an app that really cares can still call rt_timer_inquire,_stop,_start. Yea, that's good that someone else brings this topic up again! :) I've been pointing on this several times, but as we did not come to a conclusion how to handle the system timer in a consistent way across all skins, no one (me included...) came up with a fix of this issue so far. The thing is that most skins start the timer during module init via some parameter (nowadays also as a kernel boot option for compiled-in skins). As far as I remember, only the native and the RTAI compat skin do their own dance - the latter one has to remain compatible, ok, but the former one should be allowed to perform smarter. Ok, to be more concrete: autostarting the one-shot time in the absence of periodic mode is certainly worth considering. For the other cases and as sysfs is no option on 2.4 kernels, what about adding a /proc-exported control mechanism for the timer mode (and period) to either the HAL or the nucleus? Additionally, we could provide some CONFIG_xyz to set the default mode during compile time. Ceterum censeo rt_timer_start/stop esse delendam. ;) Jan signature.asc Description: OpenPGP digital signature
Re: [Xenomai-core] autostart timer, rt_timer_start/stop
Jan Kiszka wrote: Stefan Kisdaroczi wrote: Hi, cant the timer be started by default ? The current state (2.0.1) seems to lead to the following scenario: 1) Every app calls rt_timer_start() 2) If you call rt_timer_stop you can hurt other rt-apps, so dont call it 3) As some apps dont stop the timer, check in 1) if its already running I think most apps do not care in which mode the timer is running if it is already, and just go on, of course you can stop and restart the timer if its a wrong state, but you do not know if you hurt others. Now, as i read in the other thread that the periodic timer support isnt configured by default, why not start the oneshot timer automatic ? Like this, a 'normal' app doesnt need to fiddle with the timer and an app that really cares can still call rt_timer_inquire,_stop,_start. Yea, that's good that someone else brings this topic up again! :) I've been pointing on this several times, but as we did not come to a conclusion how to handle the system timer in a consistent way across all skins, no one (me included...) came up with a fix of this issue so far. Looks like pending, indeed: https://gna.org/bugs/?func=detailitemitem_id=4551 The thing is that most skins start the timer during module init via some parameter (nowadays also as a kernel boot option for compiled-in skins). As far as I remember, only the native and the RTAI compat skin do their own dance - the latter one has to remain compatible, ok, but the former one should be allowed to perform smarter. Ok, to be more concrete: autostarting the one-shot time in the absence of periodic mode is certainly worth considering. For the other cases and as sysfs is no option on 2.4 kernels, what about adding a /proc-exported control mechanism for the timer mode (and period) to either the HAL or the nucleus? Nucleus. Additionally, we could provide some CONFIG_xyz to set the default mode during compile time. Since we can't have more than a single timer setting at any time, a CONFIG switch in the General menu would be ok. In such a case, moving the currently arch-dep CONFIG_XENO_HW_PERIODIC_TIMER to the General config section would make sense too, so that we would have all timer options at the same place (periodic timing can always be emulated using some underlying oneshot hw timer, and all archs are expected to provide at least some form of oneshot timer anyway). Ceterum censeo rt_timer_start/stop esse delendam. ;) Perhaps not, otherwise we would have some trouble crafting tests and benchmarks for instance. But these are indeed relics from the Stone Age we'd better deprecate for normal use. Jan -- Philippe.
[Xenomai-core] [rt shared irqs] changes on the adeos-ipipe layer v.2
Hi everybody, the recent patches are enclosed here. Mmm I haven't ported it to the recent adeos-ipipe xeno though but I guess it's not a big obstacle for possible design-related comments etc. just to note some main issues... o the ipipe_virtualize_irq() interface now includes an additional param, namely - void *cookie. o ipipe_domain::cpudata::irq_hits has been renamed to irq_pending_hits while irq_hits now stands for the former rthal_realtime_irq::irq_hits. It's incremeneted in ipipe_irq_handle() and ipipe_schedule_irq(), IOW at the places where irqs (normal or virtual) become visible on the adeos radar first time. Another approach would be to increment it in ipipe_sync_stage() right before calling actual isr handlers. This way, accounting (well, it depends what are we going to count though) would be wrong for virq and ipipe_tick_irq handler. er.. I was confused by the fact that sum of all apcs in /proc/xenomai/apc != virq from /proc/xenomai/irq, but ipipe_printk_virq is not listed since it's registered without rthal::apc interface. Ok, should take a look at it closer, i.e. maybe at least rthal_linux_irq can be reworked now. -- Best regards,Dmitry Adamushko ipipe-i386-1.0-10-ext-2.patch Description: Binary data xenomai-2.1-i386-ext-2.patch Description: Binary data
