OSDev.org

Is this how I disable the BIOS defaults (for Interrupts)? Which method (for the ISRs) would be better for a beginner (Plain Assembly or Two-Stage Assembly Wrapping)? Is there also some example code for the ISRs?

Sorry if this is too many questions.

zap8600 wrote:Is this how I disable the BIOS defaults (for Interrupts)?

Yes, initializing the legacy PICs is the only way to change how the PICs map ISA IRQs to interrupt vectors.

zap8600 wrote:Which method (for the ISRs) would be better for a beginner (Plain Assembly or Two-Stage Assembly Wrapping)?

Using an assembly wrapper around a C function means you can write your ISR in C. Do you want to write your ISR in C?

zap8600 wrote:Is there also some example code for the ISRs?

Not really. Other than sending EOIs, the things your ISRs will need to do will be very specific to your OS.

Octocontrabass wrote: Using an assembly wrapper around a C function means you can write your ISR in C. Do you want to write your ISR in C?

I feel way more comfortable coding in C than in Assembly.

Little side question.
Is it possible to compile the kernel from the Meaty Skeleton tutorial as myos.bin instead of myos.kernel?

zap8600 wrote:I feel way more comfortable coding in C than in Assembly.

Then you should use an assembly wrapper that calls a C function.

zap8600 wrote:Is it possible to compile the kernel from the Meaty Skeleton tutorial as myos.bin instead of myos.kernel?

You can change the kernel file name to whatever you want. Or are you asking how to compile it to a different binary format?

Octocontrabass wrote: Then you should use an assembly wrapper that calls a C function.

Does the wiki contain info on making the ISRs in C?

Octocontrabass wrote: You can change the kernel file name to whatever you want. Or are you asking how to compile it to a different binary format?

I do mean in a different format. I'll look into it.

zap8600 wrote:Does the wiki contain info on making the ISRs in C?

Like this?

zap8600 wrote:I do mean in a different format.

Why do you want your kernel to be in a different format?

Octocontrabass wrote: Like this?

Yes. Thanks.

Octocontrabass wrote: Why do you want your kernel to be in a different format?

Its just a problem with QEMU being unable to load the myos.kernel file. I would like to just load the kernel.

zap8600 wrote:Its just a problem with QEMU being unable to load the myos.kernel file. I would like to just load the kernel.

So why not ask for help with that in the first place?

Octocontrabass wrote: So why not ask for help with that in the first place?

I don't know.
Right now, I'm currently working on the terminal driver's scrolling support and the IDT.

Since I am booting with GRUB, do I have to initialize the PIC? It says something about not needing to if you are using GRUB here.

zap8600 wrote:Since I am booting with GRUB, do I have to initialize the PIC? It says something about not needing to if you are using GRUB here.

It says you must initialize the PICs no matter which bootloader you're using. Where did you get the idea that you don't have to if you're using GRUB?

Octocontrabass wrote: It says you must initialize the PICs no matter which bootloader you're using. Where did you get the idea that you don't have to if you're using GRUB?

Nevermind. I'm just being dumb. I'll remap the PIC and figure out how to create the ISRs in C.

How would I write an ISR in C?
The following code is from the wiki. What does the function need to do? How many of these do I need to define? What does interrupt_frame need to be?
Or does this handle the ISRs and the ISRs are different?

I'll wait to ask more questions.

EDIT: I'm sorry for being annoying. I'm just very, very confused. I have example code, I'm just confused on how to make some code based on the example.

zap8600 wrote:How would I write an ISR in C?

In a typical OS, you would need an assembly wrapper to save and restore the registers so you can manipulate the task's state. To keep code size down, you can have 256 entry points (one for each ISR) that push the vector onto the stack and jump to a common assembly wrapper, and then pass that value to the C function so it can dispatch a handler depending on the interrupt vector.

zap8600 wrote:The following code is from the wiki.

GCC's __attribute__((interrupt)) is meant for things like single-threaded bare metal programs. It's not suitable for an OS.

zap8600 wrote:What does the function need to do?

That depends on what caused the interrupt. If it's an exception, you'll probably want to display the contents of the saved registers and halt the CPU for now. (In the future, you might instead terminate the offending program, or send a signal, or fix whatever caused the exception and return.) If it's a hardware interrupt, you need to respond appropriately for the hardware in question. That might mean calling a driver handler, or it might mean masking the IRQ and waking a driver thread, or maybe something else.

zap8600 wrote:How many of these do I need to define?

At minimum, you need enough to cover the CPU's exception vectors and whichever hardware IRQs you want to support. They can all share most of the code, as long as each has a unique entry point that keeps track of the vector somehow.

The CPU itself supports up to 256 vectors, and you may end up needing all them in the future.

zap8600 wrote:What does interrupt_frame need to be?

A struct that matches the layout of the values placed on the stack. Since you should be writing your own assembly stub, what goes into the struct will depend on the assembly code you write.

zap8600 wrote:Or does this handle the ISRs and the ISRs are different?

Different from what?

I have returned. After a bit of trouble, I know what I need to do, thanks to everyone here. I am sorry for being very annoying. I have one last question. Where would I put the GDT, IDT, PIT, and keyboard code in the Meaty Skeleton code? Thanks in advance for any help.

GDT and IDT code should go under kernel/arch/i386 since those are specific to the CPU architecture.

PIT code might go there as well, since timers tend to be pretty important to architecture-specific code, but there are at least two CPU architectures that use the PIT, so it may be a better idea to place it in a new directory specifically for architecture-agnostic drivers.

Keyboard code should go in that same new directory for architecture-agnostic drivers. If you're specifically talking about the PS/2 keyboard, then you'll also need to separate the code for the PS/2 controller and the PS/2 keyboard into two drivers, since it's possible to have one without the other.