[haiku-gsoc] Re: New timer patch (again) (Was: Re: First timer.diff (from private e-mails))

  • From: "Dustin Howett" <alaricx@xxxxxxxxx>
  • To: haiku-gsoc@xxxxxxxxxxxxx
  • Date: Fri, 4 Jul 2008 13:22:41 -0400

sPriority being a variable was an artifact from using -1 prio to
denote uninitialized timers. Thanks for pointing both of these out!
I'll send one more patch for this to the ml and hope that it's the
one. Thanks for all your help and I look forward to writing HPET
support.

On Fri, Jul 4, 2008 at 9:30 AM, Axel Dörfler <axeld@xxxxxxxxxxxxxxxx> wrote:
> "Dustin Howett" <alaricx@xxxxxxxxx> wrote:
>> Revision 9: ChangeLog
>>  - sBestTimer -> sTimer, currentPriority -> bestPriority,
>> timerPriority -> priority
>>  - Panic when a timer can't be used.
>>    - As a consequence of this, I removed the "if (sTimer != NULL)"
>> checks from set/clear hardware timer, because we'll never get that
>> far
>> without sTimer.
>>  - Move apic's special init into its own function for arch_smp.c to
>> call. Keep init around for the timer crawling code to not reject it
>> and not have to write a special case into the loop.
>>  - Fix most () != (void) issues, except for interrupt handlers,
>> because install_io_interrupt_handler and the like don't like (void)
>> methods.
>
> If you mean:
>> +static int32
>> +apic_timer_interrupt()
>
> This is not surprising, as the interrupt function signature is int32
> handler(void *data) - while () is allowed as a substitute (because
> (...) implies that, too), (void) is not, obviously. You should add the
> (void *data) part, though.
> BTW is there any reason to have sPriority in the timers a static but
> not const? If you ask me, you could just return "1" or whatever
> suitable from the get_priority() function directly.
>
> Thanks again! :-)
> Since I'm almost away now, I let Stefano apply the patch. I'm looking
> forward to your HPET work!
>
> Bye,
>   Axel.
>
>
>



-- 

- DH

Other related posts: