Em Segunda 13 Março 2006 15:33, Jan Kiszka escreveu:
>Rodrigo Rosenfeld Rosas wrote:
>> Em Segunda 13 Março 2006 14:25, Gilles Chanteperdrix escreveu:
>>> Jan Kiszka wrote:
>>>>> Sometimes the result is "Should be near 84000: 100000", that is kind of
>>>>> correct, since the tickval is 100000, although I think that those
>>>>> functions in the RTDM driver context should be independent of the tick
>>>>> value set by the user program... Maybe using oneshot in the driver
>>>>> calls and periodic in the application... I really don't know what would
>>>>> be the best approach here...
>>>> rtdm_clock_read always uses the nucleus clock. Using something different
>>>> (e.g. always TSC) would break applications specifying absolute times
>>>> derived from the return values of other skins' functions.
>>> Maybe adding a service to RTDM would allow users to measure short time
>>> intervals with RTDM using the TSC ?
>>> The native (rt_timer_tsc()) and posix (clock_gettime(CLOCK_MONOTONIC))
>>> skins have a way to do this.
>> This would fit great for my needs (and most developers I think)!
>Will think about it. Actually, I'm not a big fan of this. It creates the
>risk that someone feeds the output of this service into (incompatible)
>timed RTDM services.
Sorry, I couldn't see a practical usage of this. Could you give an example?
>Even worse, this would work for aperiodic mode but fail for periodic.
Actually it is only necessary on periodic modes as it already works for
>We would definitely need a good name for it,
>rtdm_clock_read_monotonic()? I'm not going to break rtdm_clock_read() by
>adding an argument (otherwise, I would have to fix too many drivers on
>my own... :-/).
That is the idea, I think. I agree that rtdm_clock_read() should be kept as it
is (the API/definition). No body is asking you to change it. Adding
rtdm_clock_read_tsc() would be sufficient in my opinion whilst it maintain
coherency with other skins.
Thank you for considering it.
Yahoo! Acesso Grátis - Internet rápida e grátis. Instale o discador agora!
Xenomai-core mailing list