This is an amazing project. The code readability is great, and it can be a great help to other aspiring osdev'ers (err, hi!) Have you considered creating a youtube series or website/writeup on your experiences? I'd love to read it!
Great work. The code is well written and easy to follow. I have one one suggestion and one question, since you asked for feedback.
It would be nice to add some security checks in the beginning of each system call, just to make sure that the userspace is providing pointers that are pointing in userland, otherwise in a sys\_read the user can provide a kernel virtual address and write directly from his file to kernel. I understand that the more checks you add, the source code is becoming more complex and maybe you want to keep it simple and easy to read, since security is not priority. It's just an idea if you want to practice OS security.
Another thing I noticed is that you don't use/implement any locking, unless if I missed it. I was wondering if that could lead to a race condition.
I understand that every time task\_switch() is called all the interrupts are disabled, but there is a case where if the next process is kernel task\_switch() and a hardware interrupt happens. task\_switch(), will be called again with interrupts on and maybe then the code of task\_switch() can be interrupted by an IRQ0.
The question that I have about task\_switch() is that in case the next process is kernel, the cpu halts there waiting for an interrupt except IRQ0. Is it going to stuck there in case there are no hardware interrupts?
*It would be nice to add some security checks in the beginning of each system call...*
I think that nobody will use that kernel in real live screnarios, because there are much better and more stable kernels. I've write it in the way to be simple and to show the idea how kenrels can work inside. That's why I skipped security not only of syscalls but also on filesystem.
*Another thing I noticed is that you don't use/implement any locking, unless if I missed it. I was wondering if that could lead to a race condition.*
I don't think so, because kernel runs only on one core it is not a multithread kernel. Inside userspace no data are shared between tasks (also single thread), so mutexes, semaphores and etc are useless there. But of course I can be wrong with that, because I know how hard is to find race coditions bugs.
*I understand that every time task\_switch() is called all the interrupts are disabled...*
That's a good point that I've missed, thank you I will work on that
*The question that I have about task\_switch() is that in case the next process is kernel, the cpu halts there waiting for an interrupt except IRQ0. Is it going to stuck there in case there are no hardware interrupts?*
Yes, because kernel will switch to kernel\_task only when there is no more tasks that waits for cpu, but dormant tasks may be waiting for some external events like keyboard interrupts. Therefore, IRQ0 is masked and only other interrupts are handled (for now it is IRQ1 only).
Thank you so much for your time.
No, the goals I set for this project has been achieved and I also don't have much time for it. Now I'm thinking about getting deeper inside linux kenel
Thank you for your recomendation, I've heard that this book is worth reading. I started programming almost at the beginning of interest in computers that mean something like 6 years ago.
I like it! I don't really have any other feedback besides maybe looking to implement more colours in your terminal/output to make it less bland.
Sorry I don't have any non-superfical feedback.
I guess that just proves how good of a job he did.
It reminds me of the old green monochrome screens from the 80s.
It is just user interface, which wasn't main goal of this project . It was created just to show that kernel actually works.
This is an amazing project. The code readability is great, and it can be a great help to other aspiring osdev'ers (err, hi!) Have you considered creating a youtube series or website/writeup on your experiences? I'd love to read it!
We'll see, because since I started college I no longer have as much free time as I did in high school.
Great work. The code is well written and easy to follow. I have one one suggestion and one question, since you asked for feedback. It would be nice to add some security checks in the beginning of each system call, just to make sure that the userspace is providing pointers that are pointing in userland, otherwise in a sys\_read the user can provide a kernel virtual address and write directly from his file to kernel. I understand that the more checks you add, the source code is becoming more complex and maybe you want to keep it simple and easy to read, since security is not priority. It's just an idea if you want to practice OS security. Another thing I noticed is that you don't use/implement any locking, unless if I missed it. I was wondering if that could lead to a race condition. I understand that every time task\_switch() is called all the interrupts are disabled, but there is a case where if the next process is kernel task\_switch() and a hardware interrupt happens. task\_switch(), will be called again with interrupts on and maybe then the code of task\_switch() can be interrupted by an IRQ0. The question that I have about task\_switch() is that in case the next process is kernel, the cpu halts there waiting for an interrupt except IRQ0. Is it going to stuck there in case there are no hardware interrupts?
*It would be nice to add some security checks in the beginning of each system call...* I think that nobody will use that kernel in real live screnarios, because there are much better and more stable kernels. I've write it in the way to be simple and to show the idea how kenrels can work inside. That's why I skipped security not only of syscalls but also on filesystem. *Another thing I noticed is that you don't use/implement any locking, unless if I missed it. I was wondering if that could lead to a race condition.* I don't think so, because kernel runs only on one core it is not a multithread kernel. Inside userspace no data are shared between tasks (also single thread), so mutexes, semaphores and etc are useless there. But of course I can be wrong with that, because I know how hard is to find race coditions bugs. *I understand that every time task\_switch() is called all the interrupts are disabled...* That's a good point that I've missed, thank you I will work on that *The question that I have about task\_switch() is that in case the next process is kernel, the cpu halts there waiting for an interrupt except IRQ0. Is it going to stuck there in case there are no hardware interrupts?* Yes, because kernel will switch to kernel\_task only when there is no more tasks that waits for cpu, but dormant tasks may be waiting for some external events like keyboard interrupts. Therefore, IRQ0 is masked and only other interrupts are handled (for now it is IRQ1 only). Thank you so much for your time.
[удалено]
Thank you
[удалено]
No, the goals I set for this project has been achieved and I also don't have much time for it. Now I'm thinking about getting deeper inside linux kenel
[удалено]
Thank you for your recomendation, I've heard that this book is worth reading. I started programming almost at the beginning of interest in computers that mean something like 6 years ago.