[resend] Re: RFC: New event timers infrastructure

[Cherry G. Mathew]

Dear Alexander,

On 9/8/2010 12:48 PM, Alexander Motin wrote:

>
> If you wish to work with specific event timer - you can ask et_find() to
> give one to you, specifying it's name, and if it is not yet busy - use
> if freely for whatever you want.
>

And if it is busy ? I have in mind non system timers, like stuff that 
comes on add-on boards, that can be exported timeret.h and interrupt the 
CPU. Would exporting such a timer prevent the onboard devices from 
utilising that specific timer function because its callback was busy ?


>>> There is not so much hardware that can be used as both time counter and
>>> event timer. For example, on x86:
>>>    - i8254 can do both, but preferably not at the same time and never both
>>> with event timer in one-shot mode;
>>>    - RTC - only event timer;
>>>    - LAPIC - only event timer;
>>
>> An ideal opportunity to implement:
>>
>> {
>>    mtx_lock_spin(&clock_lock);
>>    softcounter++;
>>    mtx_unlock_spin(&clock_lock);
>> }
>
> :) It will give you terrible precision or huge interrupt rate.
>

Indeed, but the abstraction could still be maintained. More practically, 
a flag could take care of this (TC_COUNTER_NONE or whatever. )


>>
>> I think the key thing I'm worried about here is consumer order. Is there
>> a way in which this can be queried/set by consumers ? I imagine a
>> generic scheduler would abstract this decision away from consumers as a
>> "scheduling policy".
>
> Are you talking about callback order in case of two simultaneous events?
> because if events are not scheduled as simultaneous (up to 64-bit
> precision) they could be called respectively to that order. Question is
> about interrupt latency or what?
>

To summarise,

My two concerns were:

I)

   a) If there is a non-optional device specific callback (like a timer 
isr) tied to specific timer on a vendor board
   b) a "generic" non-device specific callback that uses the ET 
framework and acquires the timer in "a)" before the isr/callback in "a)" 
could obtain it.

how can the API ensure that this scenario:

   i) doesn't happen
   or
   ii) can be subsequently rectified


AND

II)

Did the api need to be fleshed out separately of timertc.h ?
This is more of a political question that I don't care much about.

Cheers,

-- 
cherry