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.

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

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

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

How would I make a PS/2 controller?

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

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.

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.

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?

Which is better and/or easier?

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?

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?

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

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?

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

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.

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