OSDev.org

Holy I just realized what you said about the iretq instruction but since its an interrupts dont I need is to return from the interrupt

GhostedGaming wrote: ↑Wed Jan 07, 2026 11:42 am Holy I just realized what you said about the iretq instruction but since its an interrupts dont I need is to return from the interrupt

You do, and iretq is the correct way to do it. But if the interrupt was software-triggered from a context with interrupts disabled, when you return, interrupts will be disabled once more.

Generally, general execution contexts should always have interrupts enabled. Certainly for user mode, but also for kernel mode. The only exception is when holding a spinlock, typically when enforcing mutual exclusion on data shared between an interrupt handler and the driver for that device (top and bottom halves, etc).

Interrupt contexts can be interrupts-enabled or disabled, depending on whether you want to handle reetrancy and avoid priority inversion.

Ive came to the conclusion that I should just make a multitasking os that actually has a user space and isn't just kernel only I wanna make something that people will use I think I'll take inspiration from the Unix standards and what ever NT standards are

also thanks for the help I've learned some stuff just by reading this

GhostedGaming wrote: ↑Thu Jan 08, 2026 11:44 amIve came to the conclusion that I should just make a multitasking os that actually has a user space and isn't just kernel only

You need multitasking in the kernel before you can have multitasking in user space.

heres the new one https://github.com/Eucalyptus-OS/Eucalypt-Kernel