Implement a window manager #62

Merged

hgruniaux merged 32 commits from wm into main

2024-05-21 21:41:24 +02:00

hgruniaux commented

2024-05-19 22:09:00 +02:00

(Migrated from github.com)

No description provided.

desfreng (Migrated from github.com) reviewed

2024-05-21 11:23:58 +02:00

kernel/hardware/interrupts.cpp

Kernel Synchronous Interrupt must be processed prior any allocation possible (In case of a Data Abort, we want to retrieve it !)
I don't known if all the call made by the ContextSwitcher do not allocate memory but in both case, it's a pain to check & maintains. Knowing that we will panic on a synchronous interrupt in the kernel, I prefer to process them first and panic quickly to not have the time to make other errors... (do_kernelspace_interrupt modification are also discussed here)

Kernel Synchronous Interrupt must be processed prior any allocation possible (In case of a Data Abort, we want to retrieve it !) I don't known if all the call made by the `ContextSwitcher` do not allocate memory but in both case, it's a pain to check & maintains. Knowing that we will panic on a synchronous interrupt in the kernel, I prefer to process them first and panic quickly to not have the time to make other errors... (`do_kernelspace_interrupt` modification are also discussed here)

desfreng (Migrated from github.com) reviewed

2024-05-21 11:25:16 +02:00

kernel/memory/mem_alloc.cpp

What is going on here ? 😂

What is going on here ? :joy:

hgruniaux (Migrated from github.com) reviewed

2024-05-21 11:42:14 +02:00

kernel/hardware/interrupts.cpp

Yep but in that case syscalls from the kernel are not processed correctly (they are coming from kernel tasks): a syscall which sleep or yield may need a context switch.

Moreover, the context switcher only does do any allocation if it must kill the previous task. This is only possible if the previous task was a kernel task that triggered a syscall (so the interrupt is entered not in the case of a data abort). Therefore, it should be safe. Even if I agree with you in the fact that it will be hard to check and maintain the constraint.

So maybe we need to check explictly if it is not a syscall.

Yep but in that case syscalls from the kernel are not processed correctly (they are coming from kernel tasks): a syscall which sleep or yield may need a context switch. Moreover, the context switcher only does do any allocation if it must kill the previous task. This is only possible if the previous task was a kernel task that triggered a syscall (so the interrupt is entered not in the case of a data abort). Therefore, it should be safe. Even if I agree with you in the fact that it will be hard to check and maintain the constraint. So maybe we need to check explictly if it is not a syscall.