Re: [Xenomai-core] Towards periodic mode over aperiodic timers

[Philippe Gerum <rpm@xenomai.org>]

On Fri, 2006-08-18 at 14:14 +0200, Jan Kiszka wrote:
> Philippe Gerum wrote:
> > On Thu, 2006-08-17 at 15:27 +0200, Jan Kiszka wrote:
> >> Hi,
> >>
> >> the conflict between skins preferring aperiodic timing vs. skin
> >> requiring periodic mode popped up once again on xenomai-help. One way
> >> out of this, likely THE way, is to map such tick-driven skins on a
> >> periodic timer over aperiodic mode (and drop periodic low-level support
> >> completely at the same time).
> >>
> >> Let's start some discussion how this can be done, specifically as Gilles
> >> and I are already turning the xntimer subsystem upside down (almost). If
> >> we want co-existence of high-res timing of, say, the posix skin while
> >> the vxworks skin runs over a tick-timer, we need some kind of "context"
> >> for timing related functions.
> >>
> >> Simple example: xnpod_suspend_thread() expects a timeout as "xnticks",
> >> i.e. either in nanoseconds or in ticks of the underlying periodic timer.
> >> This depends on the global timer mode of the pod, and that's a no-go for
> >> concurrent modes as sketched above. Rather, the thread should encode
> >> which kind of timing mode to use, even better the threads timers.
> >>
> >> We currently dispatch xntimer_start globally to the different timer
> >> subsystems (if periodic mode is enabled). What about deriving the start
> >> function from the timer itself in the future? If a timer was created as
> >> aperiodic, things happen as usual in aperiodic mode, and the timeout are
> >> interpreted as nanoseconds. If the timer is periodic, we interpret the
> >> timeout in ticks and map them on a second-level timing subsystem
> >> (probably a wheel) that itself is driven by a single periodic timer in
> >> the first-level system (just like the host tick).
> >>
> >> Am I heading in the right direction? Is it feasible? Any other ideas?
> > 
> > I like this idea; it's simple and elegant, having only a low impact on
> > the existing interfaces.
> > 
> > The two-level timer handling moving the BSD wheel on top of the
> > aperiodic shot is definitely a clean approach, which adds no overhead to
> > the existing periodic timer management. This would also allow to get rid
> > of the specific Adeos support for periodic hw management.
> > 
> 
> One could then even think about making the support switch for periodic
> mode a per-skin option for those that support both modes.
> 
> That all sounds thrilling, but will certainly require some noticeable
> refactoring. Maybe we can start with adding the required bits to the
> existing aperiodic timer subsystem while keeping the periodic
> infrastructure. Oh my dear, I'm already regretting having made that
> suggestion... ;)
> 

Before we start implementing anything, there is still another issue (at
least) to address: how do we deal with the wall clock time, basically
xnpod_get_time/set_time, and the xnarch-level counterparts, after we
move the logic from the central pod to a per-thread/per-timer view? E.g. what
should xnpod_get_time() return when called over an ISR context? 

-- 
Philippe.