[Xenomai-help] xnpod_announce_tick when migrating from 2.3 to 2.4

[Xenomai-help] xnpod_announce_tick when migrating from 2.3 to 2.4

[Thomas Necker]

Hello

I'm trying to migrate our software from 2.3 to 2.4 and I'm struggling
with the new timebase concept.
Here is how it works in 2.3:
- I have a small kernel module that calls xnpod_stop_timer and then
xnpod_start_timer with a handling function of my own.
- This handling function does some housekeeping and then calls
xnpod_announce_tick to trigger the nucleus (and eventually the pSOS
skin).
This is basically what Philippe suggested about a year ago.
Now, all these functions are gone in 2.4, how's the best way to do
something similar now?
I couldn't figure out how the new timebase concept can be used for that.
Thanks in advance.

Regards,
Thomas

Re: [Xenomai-help] xnpod_announce_tick when migrating from 2.3 to 2.4

[Jan Kiszka]

Thomas Necker wrote:
> Hello
> 
> I'm trying to migrate our software from 2.3 to 2.4 and I'm struggling
> with the new timebase concept.
> Here is how it works in 2.3:
> - I have a small kernel module that calls xnpod_stop_timer and then
> xnpod_start_timer with a handling function of my own.
> - This handling function does some housekeeping and then calls
> xnpod_announce_tick to trigger the nucleus (and eventually the pSOS
> skin).
> This is basically what Philippe suggested about a year ago.
> Now, all these functions are gone in 2.4, how's the best way to do
> something similar now?
> I couldn't figure out how the new timebase concept can be used for that.
> Thanks in advance.

Why do you need to hook into the internals of the timekeeping system?
Why not simply register some xntimer with the unmodified core? Sorry in
case that the original thread explains this, but I don't have it at hand.

Jan

-- 
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux

Re: [Xenomai-help] xnpod_announce_tick when migrating from 2.3 to 2.4

[Thomas Necker]

> > I'm trying to migrate our software from 2.3 to 2.4 and I'm 
> struggling 
> > with the new timebase concept.
> > Here is how it works in 2.3:
> > - I have a small kernel module that calls xnpod_stop_timer and then 
> > xnpod_start_timer with a handling function of my own.
> > - This handling function does some housekeeping and then calls 
> > xnpod_announce_tick to trigger the nucleus (and eventually the pSOS 
> > skin).
> > This is basically what Philippe suggested about a year ago.
> > Now, all these functions are gone in 2.4, how's the best way to do 
> > something similar now?
> > I couldn't figure out how the new timebase concept can be 
> used for that.
> > Thanks in advance.
> 
> Why do you need to hook into the internals of the timekeeping system?
> Why not simply register some xntimer with the unmodified 
> core? Sorry in case that the original thread explains this, 
> but I don't have it at hand.

We ported a pretty large pSOS legacy application that just relied on
that behaviour. And I wanted to make as few changes as possible when
changing to Xenomai. Not only that I was new to Xenomai, I also didn't
oversee all the possible side effects in our application.

Re: [Xenomai-help] xnpod_announce_tick when migrating from 2.3 to 2.4

[Jan Kiszka]

Thomas Necker wrote:
>>> I'm trying to migrate our software from 2.3 to 2.4 and I'm 
>> struggling 
>>> with the new timebase concept.
>>> Here is how it works in 2.3:
>>> - I have a small kernel module that calls xnpod_stop_timer and then 
>>> xnpod_start_timer with a handling function of my own.
>>> - This handling function does some housekeeping and then calls 
>>> xnpod_announce_tick to trigger the nucleus (and eventually the pSOS 
>>> skin).
>>> This is basically what Philippe suggested about a year ago.
>>> Now, all these functions are gone in 2.4, how's the best way to do 
>>> something similar now?
>>> I couldn't figure out how the new timebase concept can be 
>> used for that.
>>> Thanks in advance.
>> Why do you need to hook into the internals of the timekeeping system?
>> Why not simply register some xntimer with the unmodified 
>> core? Sorry in case that the original thread explains this, 
>> but I don't have it at hand.
> 
> We ported a pretty large pSOS legacy application that just relied on
> that behaviour. And I wanted to make as few changes as possible when
> changing to Xenomai. Not only that I was new to Xenomai, I also didn't
> oversee all the possible side effects in our application.

Thanks, follow-up postings by Philippe pointed me to the requirement of
some skin APIs to have a hook into the tick handler. That's cheaper and
simpler to handle compared to a separate (master-base) timer.

Jan

-- 
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux

Re: [Xenomai-help] xnpod_announce_tick when migrating from 2.3 to 2.4

[Philippe Gerum]

On Thu, 2007-10-18 at 14:11 +0200, Thomas Necker wrote:
> Hello
> 
> I'm trying to migrate our software from 2.3 to 2.4 and I'm struggling
> with the new timebase concept.
> Here is how it works in 2.3:
> - I have a small kernel module that calls xnpod_stop_timer and then
> xnpod_start_timer with a handling function of my own.
> - This handling function does some housekeeping and then calls
> xnpod_announce_tick to trigger the nucleus (and eventually the pSOS
> skin).
> This is basically what Philippe suggested about a year ago.
> Now, all these functions are gone in 2.4, how's the best way to do
> something similar now?
> I couldn't figure out how the new timebase concept can be used for that.
> Thanks in advance.
> 

It's actually much simpler with 2.4. You may install a hook into the
periodic tick handler by calling the following helper, somewhere in your
module init code:

	xntbase_set_hook(psos_tbase, your_psos_hook);

The only difference compared to your current approach is that Xenomai
will have processed the incoming tick before calling your hook, so you
don't need to forward the tick anymore. Sidenote: this only works with
periodic timebases so far.

You may want to have a look at the VxWorks skin (sysLib.c), which
interposes on the global tick this way.

> Regards,
> Thomas
> 
> _______________________________________________
> Xenomai-help mailing list
> Xenomai-help@domain.hid
> https://mail.gna.org/listinfo/xenomai-help
-- 
Philippe.

Re: [Xenomai-help] xnpod_announce_tick when migrating from 2.3 to 2.4

[Philippe Gerum]

On Thu, 2007-10-18 at 15:27 +0200, Philippe Gerum wrote:
> On Thu, 2007-10-18 at 14:11 +0200, Thomas Necker wrote:
> > Hello
> > 
> > I'm trying to migrate our software from 2.3 to 2.4 and I'm struggling
> > with the new timebase concept.
> > Here is how it works in 2.3:
> > - I have a small kernel module that calls xnpod_stop_timer and then
> > xnpod_start_timer with a handling function of my own.
> > - This handling function does some housekeeping and then calls
> > xnpod_announce_tick to trigger the nucleus (and eventually the pSOS
> > skin).
> > This is basically what Philippe suggested about a year ago.
> > Now, all these functions are gone in 2.4, how's the best way to do
> > something similar now?
> > I couldn't figure out how the new timebase concept can be used for that.
> > Thanks in advance.
> > 
> 
> It's actually much simpler with 2.4. You may install a hook into the
> periodic tick handler by calling the following helper, somewhere in your
> module init code:
> 
> 	xntbase_set_hook(psos_tbase, your_psos_hook);
> 
> The only difference compared to your current approach is that Xenomai
> will have processed the incoming tick before calling your hook, so you
> don't need to forward the tick anymore. Sidenote: this only works with
> periodic timebases so far.
> 

Actually, I now think we should rather implement to the traditional
"daisy-chain" pattern here, with the user-defined hook being called in
replacement of the genuine tick processing code, and the hook expected
to call into xntbase_tick() to signal the incoming tick when it sees
fit. This would allow the skin to implement time slowdowns etc.

Thomas, I'm going to send a patch asap to this end. Please rely on the
common behaviour (i.e. daisy-chain) you would expect from pSOS.

> You may want to have a look at the VxWorks skin (sysLib.c), which
> interposes on the global tick this way.
> 
> > Regards,
> > Thomas
> > 
> > _______________________________________________
> > Xenomai-help mailing list
> > Xenomai-help@domain.hid
> > https://mail.gna.org/listinfo/xenomai-help
-- 
Philippe.

Re: [Xenomai-help] xnpod_announce_tick when migrating from 2.3 to 2.4

[Philippe Gerum]

[-- Attachment #1: Type: text/plain, Size: 1173 bytes --]

On Thu, 2007-10-18 at 15:43 +0200, Philippe Gerum wrote:
> > It's actually much simpler with 2.4. You may install a hook into the
> > periodic tick handler by calling the following helper, somewhere in
> your
> > module init code:
> > 
> > 	xntbase_set_hook(psos_tbase, your_psos_hook);
> > 
> > The only difference compared to your current approach is that
> Xenomai
> > will have processed the incoming tick before calling your hook, so
> you
> > don't need to forward the tick anymore. Sidenote: this only works
> with
> > periodic timebases so far.
> > 
> 
> Actually, I now think we should rather implement to the traditional
> "daisy-chain" pattern here, with the user-defined hook being called in
> replacement of the genuine tick processing code, and the hook expected
> to call into xntbase_tick() to signal the incoming tick when it sees
> fit. This would allow the skin to implement time slowdowns etc.
> 
> Thomas, I'm going to send a patch asap to this end. Please rely on the
> common behaviour (i.e. daisy-chain) you would expect from pSOS.

Here we are. This patch is against 2.4-rc4, and allows to implement a
daisy-chain of tick handlers.

-- 
Philippe.


[-- Attachment #2: tick-daisy-chain.patch --]
[-- Type: text/x-patch, Size: 1776 bytes --]

Index: include/nucleus/timer.h
===================================================================
--- include/nucleus/timer.h	(revision 3081)
+++ include/nucleus/timer.h	(working copy)
@@ -710,6 +710,8 @@
 
 void xntimer_tick_periodic(xntimer_t *timer);
 
+void xntimer_tick_periodic_inner(xntslave_t *slave);
+
 void xntimer_adjust_all_aperiodic(xnsticks_t delta);
 
 #ifdef CONFIG_SMP
Index: ksrc/nucleus/timer.c
===================================================================
--- ksrc/nucleus/timer.c	(revision 3081)
+++ ksrc/nucleus/timer.c	(working copy)
@@ -465,9 +465,8 @@
  * @note Only active timers are inserted into the timer wheel.
  */
 
-void xntimer_tick_periodic(xntimer_t *mtimer)
+void xntimer_tick_periodic_inner(xntslave_t *slave)
 {
-	xntslave_t *slave = timer2slave(mtimer);
 	xnsched_t *sched = xnpod_current_sched();
 	xntbase_t *base = &slave->base;
 	xntlholder_t *holder;
@@ -502,9 +501,17 @@
 	}
 
 	xnpod_do_rr();		/* Do round-robin management. */
+}
 
-	if (base->hook)
+void xntimer_tick_periodic(xntimer_t *mtimer)
+{
+	xntslave_t *slave = timer2slave(mtimer);
+	xntbase_t *base = &slave->base;
+
+	if (unlikely(base->hook))
 		base->hook();
+	else
+		xntimer_tick_periodic_inner(slave);
 }
 
 static void
Index: ksrc/nucleus/timebase.c
===================================================================
--- ksrc/nucleus/timebase.c	(revision 3081)
+++ ksrc/nucleus/timebase.c	(working copy)
@@ -475,9 +475,8 @@
 	if (base == &nktbase)
 		xntimer_tick_aperiodic();
 	else {
-		unsigned cpu = xnarch_current_cpu();
-		struct percpu_cascade *pc = &base2slave(base)->cascade[cpu];
-		xntimer_tick_periodic(&pc->timer);
+		xntslave_t *slave = base2slave(base);
+		xntimer_tick_periodic_inner(slave);
 	}
 
 	xnlock_put_irqrestore(&nklock, s);

Re: [Xenomai-help] xnpod_announce_tick when migrating from 2.3 to2.4

[Thomas Necker]

> > > The only difference compared to your current approach is that
> > Xenomai
> > > will have processed the incoming tick before calling your hook, so
> > you
> > > don't need to forward the tick anymore. Sidenote: this only works
> > with
> > > periodic timebases so far.
> > > 
> > 
> > Actually, I now think we should rather implement to the traditional 
> > "daisy-chain" pattern here, with the user-defined hook 
> being called in 
> > replacement of the genuine tick processing code, and the 
> hook expected 
> > to call into xntbase_tick() to signal the incoming tick 
> when it sees 
> > fit. This would allow the skin to implement time slowdowns etc.
> > 
> > Thomas, I'm going to send a patch asap to this end. Please 
> rely on the 
> > common behaviour (i.e. daisy-chain) you would expect from pSOS.
> 
> Here we are. This patch is against 2.4-rc4, and allows to 
> implement a daisy-chain of tick handlers.

Thanks for the quick fix. We were just discussing if (and if yes what
kind of) implications it has when the housekeeping is done afterwards.
It currently relies on being called before the nucleus gets the tick.
But of course I'm happy when the behaviour stays 2.3-like.
In the course of this discussion we thought about rewriting our code
so that we don't need the hook anymore. This could be possible with
moderate effort if there were some global variable available that
just counts the ticks and that could be read by the application. Is
there something like that available?

Btw:
ksrc/skins/psos+ needs an EXPORT_SYMBOL(psos_tbase) added at the
end for the patch to work.

Thanks again,
Thomas

Re: [Xenomai-help] xnpod_announce_tick when migrating from 2.3 to2.4

[Philippe Gerum]

On Thu, 2007-10-18 at 17:58 +0200, Thomas Necker wrote:
> > > > The only difference compared to your current approach is that
> > > Xenomai
> > > > will have processed the incoming tick before calling your hook, so
> > > you
> > > > don't need to forward the tick anymore. Sidenote: this only works
> > > with
> > > > periodic timebases so far.
> > > > 
> > > 
> > > Actually, I now think we should rather implement to the traditional 
> > > "daisy-chain" pattern here, with the user-defined hook 
> > being called in 
> > > replacement of the genuine tick processing code, and the 
> > hook expected 
> > > to call into xntbase_tick() to signal the incoming tick 
> > when it sees 
> > > fit. This would allow the skin to implement time slowdowns etc.
> > > 
> > > Thomas, I'm going to send a patch asap to this end. Please 
> > rely on the 
> > > common behaviour (i.e. daisy-chain) you would expect from pSOS.
> > 
> > Here we are. This patch is against 2.4-rc4, and allows to 
> > implement a daisy-chain of tick handlers.
> 
> Thanks for the quick fix. We were just discussing if (and if yes what
> kind of) implications it has when the housekeeping is done afterwards.
> It currently relies on being called before the nucleus gets the tick.

Yeah, I suspected your timer handlers were depending on the action
performed by the hook, e.g. to setup some global environment before the
application code proceeds. It's not that pretty, but a fairly common
pattern with traditional RTOS though.

> But of course I'm happy when the behaviour stays 2.3-like.
> In the course of this discussion we thought about rewriting our code
> so that we don't need the hook anymore. This could be possible with
> moderate effort if there were some global variable available that
> just counts the ticks and that could be read by the application. Is
> there something like that available?
> 

xntbase_get_jiffies(psos_tbase) would do the trick. This said, the
hook-based internal interface will always be provided by Xenomai; it's a
requirement for skins which define a user interface to interpose on the
global tick (e.g. VxWorks's sysClkConnect()).

> Btw:
> ksrc/skins/psos+ needs an EXPORT_SYMBOL(psos_tbase) added at the
> end for the patch to work.

Ack.

> 
> Thanks again,
> Thomas
-- 
Philippe.