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
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
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.
Yahoo! Acesso Grátis - Internet rápida e grátis. Instale o discador agora!
Xenomai-core mailing list