Re: [Xenomai-core] RTDM timeout value

[Jan Kiszka <jan.kiszka@domain.hid>]

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

Philippe Gerum wrote:
> On Wed, 2007-08-29 at 16:32 +0200, Jan Kiszka wrote:
>> Markus Osterried (BA/EDD) wrote:
>>> Hi,
>>>
>>> it seems that in the RTDM API, all the timeout functions which use
>>> nanosecs_rel_t have a strange behaviour.
>>> The timeout in nanoseconds is converted to ticks and the number of ticks
>>> is rounded down. So when we want to wait e.g. 500000 nanoseconds and the
>>> timertick is 1 ms, xnpod_ns2ticks() rounds down to 0. But 0 is the
>>> special value RTDM_TIMEOUT_INFINITE, so we wait forever. I use Xenomai
>>> 2.3.1, but I think it's basically the same in trunk.
>> It should even impact other skins as well when in tick-based timing
>> mode. I would bet more users of xnpod_ns2ticks() may have overseen this
>> rounding issue - like RTDM did.
>>
> 
> Other skins may only mean POSIX and native, since the other ones only
> deal with ticks.

Ah, yeah, of course.

POSIX is safe because it does well-defined rounding on its own. Native
itself has no problem, just the user may get informed about the rounding
behaviour of rt_timer_ns2ticks. Otherwise, things like rt_sem_p(sem,
rt_timer_ns2ticks(some_nanos)) may unexpectedly behave like RTDM does now.

> 
>>> Wouldn't it be better to round up the ticks instead of round it down?
>> Hmm, probably. Mind to work out a patch for xnpod_ticks2ns()?
>>
>> What do others think about this issue? Can/should we change the rounding
>> behaviour at nucleus level?
>>
> 
> Clearly not. You don't change the core rounding policy for fixing
> shortcomings in the higher levels, especially to fix invalid application
> requests. I do want to be able to round down at nucleus level, which I
> would not be able to do anymore with a rounding up policy at core level.
> This change belongs to the skin which wants this behaviour.

Agreed, we primarily need to fix RTDM here.

But what about introducing generic xnpod/xntbase_ns2ticks_floor/ceil()
for this? Would avoid more re-inventions of this common service.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]