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. Jan
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
