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.


Attachment: signature.asc
Description: OpenPGP digital signature

Xenomai-core mailing list

Reply via email to