Rod Pemberton wrote:
[..]
> Sorry, my mistake. I should have asked if interrupts were disabled (IF
> cleared) for the entire routine. I wrapper my IRQ routines with CLI/STI
> because they go through a trap gate. This shouldn't affect you. I was
> considering that interrupts might be enabled for part of the IRQ
routine,
> and that it might be a problem.
> Anyway, Ben thinks it might work better with interrupts enabled.
> It's worth a shot. I usually try all combinations anyway. :-)
> Helps to learn new stuff - even if painful...
> The problem I experienced with my personal OS was corruption of static
or
> shared data. Since my IRQ routines were becoming quite large, I enabled
> interrupts for non-critical ****tions of the routines.
[...]
My first OS attempts encountered similar effects. So I decedied to split
the story into shortest HW-related 'IRQ-routines' and 'event-handlers'.
The main idle in my OS just polls two 32-bit event-flags variables and
the main timecounter for timesliced tasks.
__________
MAIN_RESET: ;at start and after fatal errors
cli
LGDT... ;initialise all what's needed
....
MAIN:
sti
mov eax,[hw-events]
and eax,[hw-mask] ;may ignore ie: IRQ09 VGA-retrace
jz L0
call act_event
L0:
mov eax,[time_events] ;software and hardware time-outs
and eax,[sw-mask]
jz L1
call act_timeout
L1:
mov eax,[main_time]
cmp eax,[next_sceduled]
jc main
call next_task
jmp main
________
The IRQ00 routine only increments one main counter and decrement a set
of timeout-counters until zero (set TimeOut# event bit on 1 -> 0 only).
And I the added the 0...999 mSec counter synchronised by RTCL (IRQ8).
My 'largest' IRQ-handlers are mouse and keyboard, because this devices
fire several IRQs in certain sequences, the event-bits are only set
when the sequence is completed. I enable IRQ very early in this two, but
never encountered any problems by using 'normal' EOI (out[A0/20],20)
even KEYBD(IRQ01) and PS/2 mouse(IRQ0C) share I/O-****ts.
With 'largest' I mean larger than 64 bytes, but not more than 256,
whereas (depending on the sequence count) again maximal 64 bytes per
IRQ will be executed.
So the only possibile reentrance could occure if the KEYBD-IRQ would
handle KEYBD-LEDs on it's own, because LED-setting needs 'some' time
and a fast typist can hit two more keys meanwhile.
I experienced this as buggy behaviour and finally made CAPS,NUM,SCROLL-
LED-actions apart from IRQ-handler (event driven now).
__
wolfgang
|
