Anders Blomdell wrote:
> Jan Kiszka wrote:
>> ...
>> Thinking about this more thoroughly, a few questions popped up for me:
>> o When we call it rtdm_clock_read_tsc(), we should actually return the
>>   raw TSC values, shouln't we? But then we also need conversion
>>   functions (rtdm_clock_tsc2ns, rtdm_clock_ns2tsc). Or should we always
>>   convert to nanoseconds on return? POSIX and Native are different in
>>   this regard.
>> o What would be the core rationale behind it, having a high-resolution
>>   time stamp? What are the primary use cases? I'm asking for this so
>>   that I can clearly differentiate between this new service and the
>>   existing one in the docs. Also, giving an abstract description would
>>   leave more options to the actual implementation on other archs or
>>   platforms.
> If you implement it, don't forget to point out that the tsc may have
> increments varying over time (due to clock scaling), and might even stop
> for long periods (ACPI sleep), just so we are not faced with a primitive
> that makes it impossible to implement low-power operation (not at the
> very top on my priority list, but still important).

Yeah, one reason why I'm hesitating ATM to introduce a too specific
service to RTDM. But I'm still open to being persuaded about its usefulness.


Attachment: signature.asc
Description: OpenPGP digital signature

Xenomai-core mailing list

Reply via email to