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. Even worse, this would work for aperiodic mode but
fail for periodic.

We would definitely need a good name for it,
rtdm_clock_read_ex(<clock-id>), rtdm_clock_read_tsc(),
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... :-/).


Attachment: signature.asc
Description: OpenPGP digital signature

Xenomai-core mailing list

Reply via email to