OSDev.org

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

What files should I make? Should I make files like gdt.c and idt.c?

Octocontrabass wrote: 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.

Where will the drivers folder go? Will it go in the root folder or in the kernel folder? I also wasn't talking about the PS/2 keyboard specifically, but now that I think about it, I should start with that. It would also be good to know how to get input from an USB keyboard. How would I make a PS/2 controller?

zap8600 wrote:What files should I make? Should I make files like gdt.c and idt.c?

Sure, if you want. You can always change it later if you come up with a better way to organize things.

zap8600 wrote:Where will the drivers folder go? Will it go in the root folder or in the kernel folder?

If you're writing a typical monolithic kernel, drivers would probably go under the "kernel" directory. You don't necessarily need a "drivers" directory though - maybe you'll have one directory for each type of driver instead, like "timer" and "serial" and "keyboard".

zap8600 wrote:It would also be good to know how to get input from an USB keyboard.

USB is complex, and I'm not very familiar with it. You may want to choose something simpler so you can figure out how you want your drivers to work.

zap8600 wrote:How would I make a PS/2 controller?

You don't "make" a PS/2 controller. The PS/2 controller is the fancy serial port that you plug PS/2 keyboards and mice into. Just like an ordinary serial port, you want the driver for the port to be separate from the driver for the device plugged into the port.

Octocontrabass wrote:

zap8600 wrote:Where will the drivers folder go? Will it go in the root folder or in the kernel folder?

If you're writing a typical monolithic kernel, drivers would probably go under the "kernel" directory. You don't necessarily need a "drivers" directory though - maybe you'll have one directory for each type of driver instead, like "timer" and "serial" and "keyboard".

After going over kernel designs, I believe I will use the monolithic design. I will put the drivers folder in the kernel folder.

Octocontrabass wrote:

zap8600 wrote:How would I make a PS/2 controller?

You don't "make" a PS/2 controller. The PS/2 controller is the fancy serial port that you plug PS/2 keyboards and mice into. Just like an ordinary serial port, you want the driver for the port to be separate from the driver for the device plugged into the port.

My bad. I meant a PS/2 driver.

zap8600 wrote:My bad. I meant a PS/2 driver.

I'm not sure I understand your question. You make a driver that provides a standard software interface to interact with the hardware. For a PS/2 controller, that standard software interface might be "generic serial port" since PS/2 ports are basically fancy serial ports, but it's up to you.

PS/2 is easy, you just initialize the keyboard and/or mouse, unmask them from the PIC (Make them able to send you some interrupts), and when an interrupt occurs you just read the value from the I/O Ports (Keypress, mouse gone up or down ...).

Octocontrabass wrote: I'm not sure I understand your question. You make a driver that provides a standard software interface to interact with the hardware. For a PS/2 controller, that standard software interface might be "generic serial port" since PS/2 ports are basically fancy serial ports, but it's up to you.

I'm sorry. I'm just a bit confused by how you said the keyboard driver should be made.

Octocontrabass wrote: 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.

Could you tell me more about separating the code for the PS/2 controller? Or should I read from the 0x60 port (I believe this is where the keyboard scancode is)? Which is better and/or easier?

zap8600 wrote:Could you tell me more about separating the code for the PS/2 controller?

The PS/2 controller is a set of (usually) two fancy serial ports. Your PS/2 controller driver is responsible for sending and receiving bytes through those two serial ports and that's all. It doesn't know or care what kinds of devices are plugged into the PS/2 ports, aside from maybe detecting them so it can start the correct PS/2 device drivers.

Your PS/2 keyboard and mouse drivers don't directly interact with the hardware. They send and receive data through your PS/2 controller driver. They turn bytes received through the PS/2 controller driver into input events.

zap8600 wrote:Which is better and/or easier?

The easier choice is to ignore PS/2 entirely and pretend the PS/2 controller is a PC or XT PPI hooked up to a PC or XT keyboard. You can't support a PS/2 mouse, but maybe you don't need a mouse yet.

The better choice is to handle PS/2 as a couple of fancy serial ports that might be attached to any PS/2 device. That way, if someone does something weird like plugging in two keyboards your OS can gracefully handle it by starting two instances of your PS/2 keyboard driver. This gets tricky because things like USB legacy support and active PS/2 multiplexing can mangle the data you're sending or receiving, and some laptops require scan code translation for their Fn key functions.

Octocontrabass wrote: The better choice is to handle PS/2 as a couple of fancy serial ports that might be attached to any PS/2 device. That way, if someone does something weird like plugging in two keyboards your OS can gracefully handle it by starting two instances of your PS/2 keyboard driver. This gets tricky because things like USB legacy support and active PS/2 multiplexing can mangle the data you're sending or receiving, and some laptops require scan code translation for their Fn key functions.

What are the serial ports for the PS/2 controller?

zap8600 wrote:What are the serial ports for the PS/2 controller?

These things.

Octocontrabass wrote: These things.

I'm a bit confused. I believe I need to set up a PS/2 controller driver. How do I do that?

Are you asking what your PS/2 controller driver needs to do, or are you asking what your OS needs to do before it can run your PS/2 controller driver, or are you asking something different?

Octocontrabass wrote:Are you asking what your PS/2 controller driver needs to do, or are you asking what your OS needs to do before it can run your PS/2 controller driver, or are you asking something different?

I guess what it needs to do. Does something need to be done before the driver can be run?

I also have some side questions. Should my GDT be loaded from the boot.S file instead? If so, then how do I do that (how do I setting up the GDTR and segments as well)? How do I enable paging as well? Should I make my kernel a higher half kernel? If so, then how would I do so? I have one last side question. Once I start working on the keyboard interrupt, how do I export what the user entered (e.g. for making a scanf function in libk, so that the system calls for libc can get keyboard input)? Sorry if it is too many questions. I'm just confused and trying to understand everything.

zap8600 wrote:Does something need to be done before the driver can be run?

Ideally, you should initialize the USB controllers and use ACPI to make sure a PS/2 controller exists. You can still run your PS/2 controller driver without doing those things, and it will work perfectly fine in virtual machines, but it might behave strangely on some hardware.

zap8600 wrote:Should my GDT be loaded from the boot.S file instead?

You can if you want, but you don't need to.

zap8600 wrote:If so, then how do I do that (how do I setting up the GDTR and segments as well)?

Insert some assembly code to load the GDTR and load all of the segment registers before calling your kernel's main function. There's code earlier in this thread you could easily adapt.

zap8600 wrote:How do I enable paging as well?

Create page tables, load CR3, and set CR0.PG.

zap8600 wrote:Should I make my kernel a higher half kernel?

It's a good idea, but it's not required.

zap8600 wrote:If so, then how would I do so?

The easiest choice is to switch to a bootloader that will set up initial page tables and jump to the higher half for you. Or, if you want to stick with GRUB, you can load your actual kernel as a module and then load a small program to set up higher half paging as the "kernel".

zap8600 wrote:Once I start working on the keyboard interrupt, how do I export what the user entered (e.g. for making a scanf function in libk, so that the system calls for libc can get keyboard input)?

You'll need to buffer the data somewhere and come up with a way for applications to get the data from that buffer. I'm not very familiar with how this usually works, so I suggest searching the forums for threads about input handling.

You are asking too much questions that already have an answer in the osdev wiki.

I suggest that you better read the Intel Manual, it will answer every further CPU related question in your os development journey.

Octocontrabass wrote: Ideally, you should initialize the USB controllers and use ACPI to make sure a PS/2 controller exists. You can still run your PS/2 controller driver without doing those things, and it will work perfectly fine in virtual machines, but it might behave strangely on some hardware.

So do I need to make a USB controller driver? If I only need to initialize them, then do I use the 1.0, 2.0, or 3.0 controller(s)?

Octocontrabass wrote: It's a good idea, but it's not required.

I will be using this boot.S file to setup paging and load my kernel in the upper half.