Em Terça 14 Março 2006 03:44, Jan Kiszka escreveu:

>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.

I didn't know it was independent from the timer. Good to know. I think it 
would worth enforce this statement on its documentation.

>> 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.

Please, take a look in my case. The specification recommends wait at least Xus 
before testing a bit. But the time to wait is not constant, it can vary a few 
microseconds. So, I busy wait Xus and then do some code like:

start_time = rtdm_clock_read[_tsc]();
do {
} while (! condition && (time_passed(start_time) < TIMEOUT));

But if the user specifies a periodic timer, with tickval=1ms, then my driver 
will be too slow. I could busy wait TIMEOUT before testing, and it would be 
faster then the above code in this case. But I would like to go away as soon 
as possible, ie, just after the bit has been set...

>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

But my situation is still a busy wait but written in another form.

>So, I wonder what you plan to do with the return value of the 
>new function?

I think I've already explained myself.

Best regards,


Yahoo! Acesso Grátis - Internet rápida e grátis. Instale o discador agora!

Xenomai-core mailing list

Reply via email to