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