Trap Gates?

[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?

[Aali]

i find it easier to keep that consistant for every type of interrupt and just enable interrupts later if need be

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

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

[pcmattman]

Makes sense now .