From mboxrd@z Thu Jan 1 00:00:00 1970 Subject: Re: [Xenomai-core] Towards periodic mode over aperiodic timers From: Philippe Gerum In-Reply-To: <44E5AF32.3020102@domain.hid> References: <44E46EDC.1000707@domain.hid> <1155899619.4326.56.camel@domain.hid> <44E5AF32.3020102@domain.hid> Content-Type: text/plain Date: Fri, 18 Aug 2006 16:32:43 +0200 Message-Id: <1155911563.4326.96.camel@domain.hid> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Reply-To: rpm@xenomai.org List-Id: "Xenomai life and development \(bug reports, patches, discussions\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jan Kiszka Cc: xenomai-core 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.