Page 1 of 1
Trap Gates?
Posted: Sat Aug 18, 2007 10:32 pm
by pcmattman
I've seen the light in switching to trap gates after reads from the console device failed miserably thanks to the read function being called via a syscall (interrupt gate) and hence blocking all other interrupts (including the keyboard).
This is what I've tried to do to get trap gates working:
Code: Select all
idt_set_gate(128, (unsigned)isr128, 0x08, 0x8F);
Unfortunately, interrupts are still disabled when this trap gate is called.
Any hints?
Posted: Sat Aug 18, 2007 10:40 pm
by Aali
i find it easier to keep that consistant for every type of interrupt and just enable interrupts later if need be
Posted: Mon Aug 20, 2007 2:08 am
by JamesM
I always enable interrupts before dispatching from my 'catch-all' exception handler to the code that will actually handle the exception. Then I disable them again when it finishes.
Posted: Mon Aug 20, 2007 7:10 am
by os64dev
I've seen the light in switching to trap gates after reads from the console device failed miserably thanks to the read function being called via a syscall (interrupt gate) and hence blocking all other interrupts (including the keyboard).
normally i would make the syscall read not dependand on the keyboard read. I would have an interrupt service routine that will put the keyboard pressed in a keyboard buffer. And the read function uses that buffer for handling its state.
in pseudo code:
Code: Select all
Buffer<unsigned char> keyBuffer;
void keyBoardIsr(void) {
//- store character in keyboard buffer.
keyBuffer.AddLast(inport(0x60));
//- acknowledge interrupt.
outport(0x20, 0x20);
}
int readFromKeyBoard(void) {
if(keyBuffer.Length() > 0) {
return(keyBuffer.getFirst());
}
//- no keyboard data available.
return(-1);
}
in userland you then get a function
Code: Select all
int getch(void) {
int ch;
while((ch = syscall(readFromKeyBoard)) == -1) {
sleep(10); // wait ten milliseconds.
}
}
Posted: Mon Aug 20, 2007 3:19 pm
by pcmattman
Makes sense now
.