Philippe Gerum wrote: > Jan Kiszka wrote: >> Hi, >> >> while I originally only wanted to add timer abstraction to RTDM, I now >> have patch series for xntimer pending on my box pushing this layer >> closer to hrtimer. >> >> But before posting it for discussion (needs further testing anyway), I >> have two questions regarding some minor though not totally uninteresting >> optimisation possibilities: >> >> 1. Is calling xntimer_start() with value=XN_INFINITE a real use case? >> It's not documented explicitly. The effect of such an invocation >> looks a bit like xntimer_stop(), but I didn't find a real caller so >> far to asses it's relevance. > > xnpod_start_timer() uses this property to start the host tick relay > timer. If XNARCH_HOST_TICK is zero, then no relay is required, and the > timer should remain passive.
I see, but there is likely some other way to achieve this. The point I'm having in mind is heavy usage of xntimer_start, e.g. from inside some timer handler. RTnet could become such a user one day when we may migrate the TDMA scheduler from thread context to a timer handler. > >> >> If it is not used and could rather be declared illegal, we could safe >> the related code in the do_timer_start handlers. >> > > Dunno. To do that, we would need to carefully inspect each and every > caller, especially for the various skins, which implies to analyze the > requirements of the mimicked API too. For sure, but we will have to review and test some stuff anyway with my patches. :) > >> 2. rthal_timer_program_shot() uses explicit rthal_local_irq_save_hw on >> ia64 and i386. Given the head optimisation, IRQs should already be >> disabled when calling this service. So, can this IRQ masking be made >> depending on !CONFIG_XENO_OPT_PIPELINE_HEAD? >> > > Yes. Ok, will get integrated. Jan
Description: OpenPGP digital signature
_______________________________________________ Xenomai-core mailing list Xenomaifirstname.lastname@example.org https://mail.gna.org/listinfo/xenomai-core