OSDev.org

I recently implemented interrupts(at least in a basic form) in my hobby OS, but don't know exactly how to make use of it. I currently have a 8254 IRQ handler set up, which for now is just a counter to make sure it's working. My plan is to connect it with existing timer function to make a clock.

My OS is obviously a monotasking system which is actually just a huge C program that runs without std library. I want to implement an interrupt based keyboard driver in it, by how to do that efficiently than polling? My initial plan was to check for the value in register until it is placed by ISR, but that is just polling, in an other way, I think. Or should I do something like use hlt to halt CPU mid function and then wake up by keyboard IRQ and then retrieve the value?

Also, is there any other important use for int on my OS? All it has a interface, an editor and an interpreter, which is actually just one C program with function of each task(I wonder with this design is it even an OS? )

Yes, that's exactly what you usually do. When you're done initializing your OS, you put the CPU in an infinite loop of:

Then, when an interrupt happens (for example, the user presses a key), an interrupt is triggered (I have IRQ 1, which is the PS/2 keyboard, mapped at int 0x21.). The interrupt hander fetches the scancode from the keyboard I/O port, looks up the ASCII character for it and displays it to the screen, for example.

This is better than having the kernel poll forever, because it saves power and heat, and you won't hear your computer fan whirring crazily.

The interrupt can just fill a buffer with whatever it receives, your program can check the buffer whenever it's ready, and then act on what it finds, that way your program can do whatever it does, and won't miss any keyboard input.

An operating system is both a resource manager and an interface (between different things), it allows the user to use the hardware more effectively. If your software does that then I would call it an operating system.

More efficient by what measure? Your OS has no other work for the CPU while it's waiting for keyboard input.


Using HLT would make it more energy efficient, since the CPU will reduce its power consumption while it's halted. Just remember that the CPU will also wake up for things that are not the keyboard IRQ.


Most hardware is designed to use interrupts so that a multitasking OS can perform useful work while waiting for the hardware. You may need to use interrupts with some hardware even though your OS has nothing to do while it waits.

I am thinking of something like


Also because it is only monotasking I think I don't need a buffer, but just retrieve current value if needed or discard if not needed. In that cases buffer_stat itself become the scan code to read.

Doing complex operations in ISRs is not a great idea, because an interrupt can get trapped while you're in the middle of handling another interrupt; so any functions you call while interrupted have to be reentrant. So yes, something like that would be a good idea.



No, you should have a proper event queue. It doesn't matter that it's monotasking. Remember, an interrupt can trigger at any time. So, say you're performing a complex computation. The user may press two keys before you get a chance to handle either, and then the first one will be eaten.

Just a simple ring buffer should do it; nothing special. Then you can do something like:

I may be wrong but my interpretation of what the OP meant was this code would not be in the ISR but would be in the main loop of the OS. I agree with a ring buffer as well. I had written a Stackoverflow answer that does such a lockless ring buffer (it is real mode code but the idea is the same in protected/llong mode) and a main loop waiting with HLT in a loop to query the keyboard buffer for a scan code with some sample code: https://stackoverflow.com/a/51565739/3857942

No, a buffer is even more important in a mono tasking OS, because the user may press the Keyboard many times before your main loop is able to receive and process the value sent by the keyboard. Without buffering the input values, all but the last value received will be lost.

I use a small (32byte) ring buffer in my keyboard handler, the interrupt just stores the received value in the next available byte position.

All your keyboard handling code needs to do is check the delta between its last read position and the current position of the index in the buffer, and then deal with the byte stream accordingly.

There's a 15-byte buffer in PC keyboard hardware. However, in my DOS days, I did on very rare occasions type fast enough to fill it. (I've more commonly filled it when the PC locks up.)