Rodrigo Rosenfeld Rosas wrote: > Em Segunda 13 Março 2006 20:05, Jan Kiszka escreveu: >> ... >>>> 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. > > I would prefer returning always ns, but both solutions would fit my needs, so > I'm not really worried about this topic. > >> 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. > > As I've said, I think that it is good to give some independency to the > driver, > at least to the time related functions, for not depending on the user chosen > timer behaviour for some delay routines. Eg, I would like to wait a specified > amount of us before testing some register. That is a quite normal task when
This is what rtdm_task_busy_sleep() already provides - independent of the system timer. > developing drivers. Another one is for timeouts on short delays. In those > cases, we want a good resolution, but this should be independent of the > user's timer choice IMO. And this is something rtdm_clock_read_tsc() will obviously not be for. Again, when the user / system administrator decided to lower the timer resolution in favour of performance, it is not possible (and doesn't make sense) to circumvent this decision at driver level (except for busy waiting). So, I wonder what you plan to do with the return value of the new function? Jan
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
