OSDev.org

That's right, huh? IRQ1 is for ps/2 keyboard. I forgot that. Hmm... I hadn't realized that it would be replaced by USB drivers... That's problematic. Well worst case scenario, I can implement the base USB drivers in kernel mode, then implement the base USB drivers. But that seems redundant seeing as a more complete driver was planned for user mode anyway. Maybe a keyboard driver utilizing inheritance would suffice. But would that be difficult going from kmode to umode? I may have to use syscalls anyway making it more complicated than it has to be. I see your point. What would you suggest if I wanted to take the route I stated earlier?

I'd suggest not putting any keyboard drivers in the kernel.

If you really want a PS/2 keyboard driver in your kernel, I'd recommend keeping it as simple as possible and completely deactivating it once user mode drivers are ready to take over. I wouldn't bother trying to cooperate with user mode drivers any more than that. (Keep in mind there may not be a user mode PS/2 driver to take over! Some PCs only emulate PS/2 and have no physical PS/2 controller once the USB drivers are running.)

If you want a USB keyboard driver in your kernel, that means you'll also need drivers for USB hubs, four different USB HBAs, and some basic stuff for PCI and maybe APIC interrupt routing. I'm not sure it would count as a microkernel at that point.

TheGameMaker90 wrote: ↑Fri Jun 28, 2024 12:21 pm How then would I stop it from spamming (it only spammed when I put the division by zero code you gave me, not when I did int $0x0).

When you perform a software interrupt, the EIP saved in the interrupt frame will be the address following the int $0 instruction. This is simply how software interrupts work. Therefore, if you return, work continues normally.

However, if a real fault happens, the EIP saved in the interrupt frame will point directly at the offending instruction. You are not supposed to return from that handler unless you change EIP in the middle. You are supposed to report a crash to the offending application. Since you don't have a userspace yet, the only possible offending application is the kernel, so it would be best to just panic, that is, log the fault and halt the CPU without returning.

You cannot, in general, know if the interrupt handler got called by software interrupt or not. In case of interrupt 0, it might be possible by checking whether the instruction EIP points at is a division instruction, though with the complicated prefix structure of x86, this is also more complicated then it looks. And it is still prone to false positives. So the best thing to do is to not allow userspace to call the exception entries (userspace software interrupts are possible, just not below interrupt 0x20) and then just never use software interrupts in kernel space, and always assume you are in the fault handler because of an actual fault.

Regarding USB keyboards: You are going to have to make a pretty fundamental decision about how you want to handle devices. I made the decision not to have virtual consoles in my kernel. This means, the kernel will always simply give access to the hardware (abstracting hardware type, of course), but not put abstractions on top of that. In this case, there is no "seat" abstraction. There will be a keyboard input device, and a speaker output device, and a framebuffer, and they will be bound together by userspace policy at the most.

Also, for USB host controllers, you can pretty much get by these days with just implementing XHCI. The other three are mostly just historic curiosities, disappearing in the rearview mirror.