So I just wanted to share something that has made me quite happy lately. I’ve been wanting to learn more about operating system. I typically try to break things down to there simplest concepts. I don’t have the ability to spend lots and lots of time on this research, but I do have weekends and some times after work. The most beneficial resources so far has been a Udemy course I have purchased called “Developing a Multithreaded Kernel From Scratch”. Much of what I have learned is still a bit jumbled up in my mind. I am going to have to use additional resources to gain more insight to what I have started to learn from the course.
Some of what I have learned includes the interrupt vector table for 16bit code. So what I think this is, is a table that is pointers to code that runs when a particular interrupt happens or is received on the PIC/CPU. From what I have learned it is located at the beginning of memory and holds 256 interrupt locations at 4 bytes each. Making it use the memory from 0000:000H, 400H or 1024 bytes. The locations or offset have been predetermined for particular uses. Interrupt zero is the divide by 0 interrupt, meaning that if code divides by zero then the code that is pointed to by the interrupt vector table for interrupt zero will run when that divide by zero occurs. From what I can tell there are CPU interrupts, basically exceptions, and hardware interrupts, which handle events from hardware like keyboards, COM ports, hard drives and mice. On x86 system there are two 8259 PICs, a master and slave. I don’t understand how the PIC’s interrupt vector table offsets overlap with the CPU interrupts, but they do, somehow. The lidt is the x86 instruction that lets the program load an interrupt descriptor table to (not sure about this) a special interrupt descriptor register IDTR. Again is all the 16-bit code.
What I have learned from 32-bit code, protected mode, is that there is a similar structure the IVT called the interrupt descriptor table. I’ve been thinking one thing that it might help with managing multiple processes and the switching between them, but I am not sure if that is correct or how it would. It serves the same purpose as the IVT, expect in 32 bit protected mode. The code that the IDT points to is called an interrupt service routine and these ISR must be an important part of device drivers for OSs like Windows and Linux and bare metal type things like spin rite.
In the Udemy course the author is using QEMU to run the os and uses GDB to debug it. I don’t know much about QEMU and this is the first time I have used GDB. But it seems to me that a person would not need much memory to do the kind of research in QEMU and there must be a way to do a memory dump and see the IVT or the IDT with any interrupt service routines. I am not sure if the author takes this direction in the course to have the programmer see their code in the debugger. I think if you used symbols you could see C code when debugging live. The course does remind me of the work, or least knowledge Steve has and uses in the development of spin rite.
I guess lastly I just wanted to comment on why, because this stuff is cool, at some point (not sure how soon), I want to able to identify the code in Linux and ReactOS that sets up the IDT. This is among other areas I want to be able to identify in those kernels/Oss code bases. Anyway hopeful someone will at least be happy with the link I have provided, it really is a great course. Feedback/comments/additional insights very welcome. Thanks.
Some of what I have learned includes the interrupt vector table for 16bit code. So what I think this is, is a table that is pointers to code that runs when a particular interrupt happens or is received on the PIC/CPU. From what I have learned it is located at the beginning of memory and holds 256 interrupt locations at 4 bytes each. Making it use the memory from 0000:000H, 400H or 1024 bytes. The locations or offset have been predetermined for particular uses. Interrupt zero is the divide by 0 interrupt, meaning that if code divides by zero then the code that is pointed to by the interrupt vector table for interrupt zero will run when that divide by zero occurs. From what I can tell there are CPU interrupts, basically exceptions, and hardware interrupts, which handle events from hardware like keyboards, COM ports, hard drives and mice. On x86 system there are two 8259 PICs, a master and slave. I don’t understand how the PIC’s interrupt vector table offsets overlap with the CPU interrupts, but they do, somehow. The lidt is the x86 instruction that lets the program load an interrupt descriptor table to (not sure about this) a special interrupt descriptor register IDTR. Again is all the 16-bit code.
What I have learned from 32-bit code, protected mode, is that there is a similar structure the IVT called the interrupt descriptor table. I’ve been thinking one thing that it might help with managing multiple processes and the switching between them, but I am not sure if that is correct or how it would. It serves the same purpose as the IVT, expect in 32 bit protected mode. The code that the IDT points to is called an interrupt service routine and these ISR must be an important part of device drivers for OSs like Windows and Linux and bare metal type things like spin rite.
In the Udemy course the author is using QEMU to run the os and uses GDB to debug it. I don’t know much about QEMU and this is the first time I have used GDB. But it seems to me that a person would not need much memory to do the kind of research in QEMU and there must be a way to do a memory dump and see the IVT or the IDT with any interrupt service routines. I am not sure if the author takes this direction in the course to have the programmer see their code in the debugger. I think if you used symbols you could see C code when debugging live. The course does remind me of the work, or least knowledge Steve has and uses in the development of spin rite.
I guess lastly I just wanted to comment on why, because this stuff is cool, at some point (not sure how soon), I want to able to identify the code in Linux and ReactOS that sets up the IDT. This is among other areas I want to be able to identify in those kernels/Oss code bases. Anyway hopeful someone will at least be happy with the link I have provided, it really is a great course. Feedback/comments/additional insights very welcome. Thanks.
