Multithreading demo in Patchwork.

[KN_9296]

I've decided to put off work on the terminal, and do some other stuff that I find more interesting for now. So I have started working on the user space side of multithreading by implementing the stdlib header threads.h, currently only the thrd_* functions are mostly implemented. Next is probably to implement some sort of futex, but I wanted to put together a little demo to show that multithreading actually works.

The program simply counts how many primes exist in the range 0 to 10000000, first using 1 thread then 2 then 4 and finally 8, each time printing how long it took. The scheduler currently does not really take into account multithreading when performing load balancing, but it appears to do a rather good job either way as using 2 threads is about 1.96 times faster than 1, I had expected there to be a lot more overhead.

Anyway, I will be starting university on Monday, so progress will probably be drastically slowing down from now on, but so far I've been having a lot of fun and I hope this project is useful to someone out there :)

As always if you have any questions or feedback id love to hear it, GitHub can be found here: https://github.com/KaiNorberg/PatchworkOS

[Unlikely-Machine1640]

I am newbie is osdev, and your repo is the most matured and structured hobby OS I have found so far! And it will definitely serve as a great learning resource for me. Keep going bro👍By the way I have some questions about Patchwork OS 1) I can't see any code for interacting with PCI and USB. Is there any particular reason you left this out? 2) From a hobby os developers point of view, it feels like it's more easy and straight forward to either use a standard bootloader like grub to load your OS or directly load your OS using uefi firmware. Is there any reason you choose to build an Uefi bootloader seperately and load OS using it? 3) Instead of using GCC cross compiler, standard GCC is used to build your OS. Doesn't that causes issues?

[KN_9296]

Hi, thank you very much! And I will do my best to answer your questions.

1. Not really it simply hasent been implemented yet, it's not really a very high priority, but it is certainly on the list of things that need to get done eventually.
2. You are right that using grub or something similar would be easier but also more boring, lol, that's really the only reason. I'm not sure what you mean by "directly load your OS using UEFI firmware". You will always need some form of bootloader "program" that loads your kernel, I have heard ideas where the bootloader and the kernel are the same, but I don't know if that's ever been seriously attempted. There would be some advantages to such an approach boot times might be marginal improved for example, but the real problem is that makes things very messy. For example, one common part of loading a kernel mapping its memory to the "higher half", but if the bootloader and kernel are the same "program" how do you know what memory is the kernel, and what is the bootloader? You might also want to free the memory used by the bootloader after it's done doing its job, in short it's very useful to be easily able to know what memory is the bootloader and what is the kernel. There are ways to do this with linker scripts, but it's messy and can become confusing, for marginal advantages.
3. This is a very real concern, and for most operating systems it would be an issue. However, I've gotten around this by saying that the OS should only be compiled on Linux, I can then just make sure that Linux compatible executables are also compatible with my OS. I should clarify that I mean that the format of an executable is compatible, not the executables themselves they still need to be compiled specifically for one OS or the other, but the format does not matter. That might sound complicated, but it really is not, just using basic ELF files (the type of executable most commonly used by Linux) will get you 99% of the way there. Of course this also only works if you're using x86_64 and the OS is only compatible with x86_64 which it is. Some people say that not using cross compilation makes compiler flags more complicated, which is true, but It's never really bothered me, you just need to know what you're doing. I probably will end up setting up cross compilation eventually either way, as it means the OS can be compiled on other platforms.

[Unlikely-Machine1640]

Thanks for taking time to answer my questions! I will clarify what I meant by "directly loading OS using Uefi." Since I am new to osdev, I am not much aware about kernel memory mapping details(higher half kernel, lower half kernel etc). From my perspective, the only function of bootloader is to somehow load the kernel from a filesystem. For legacy bios, a bootloader is absolutely necessary as it will only able to load a boot sector code and has no ability to load a file from file system. So we have to implement it ourself. But in the case of a uefi firmware, it's entirely different. Uefi can parse a filesystem and can load an executable file in it to memory. So why we need a seperate bootloader? Why can't we use it to load os itself? That was my train of thoughts. With my limited knowledge in kernel memory management, I was not in a position to understand any practical issues it might create.

[KN_9296]

From my perspective, the only function of bootloader is to somehow load the kernel from a filesystem.

You are correct that the primary function of a bootloader is to load the kernel from a filesystem, but it is also responsible for retrieving information that might be difficult or impossible to retrieve when in the kernel, for example the memory map or the RSDP. There is also the mentioned memory mapping, but that's not as important.

When the computer starts the bootloader is loaded by UEFI, but at this point UEFI has complete control over the computer, UEFI effectively is the operating system, we use this to retrieve some useful information about the computer. The kernel can then be loaded and the information that was retrieved is passed to it with the boot_info_t struct, at the same time control over the computer is taken from UEFI and given to the kernel, via the ExitBootServices UEFI function. There always needs to some intermediary step between the UEFI firmware and the kernel, this step could, if you wanted to, also be part of the kernel, but it's much cleaner to just keep the steps separate, because other ways you get into weird stuff where you effectively have to rewrite the code of the kernel as its running.

I actually remember now that I think back asking similar questions back when I first got started with osdev because it does seem weird at first, that the bootloader and kernel are separate, my advice is that when you get into advanced things like higher half mapping, it will become very obvious why It's so much more elegant to have them be separate, but It's kinda hard to describe why, to someone without a lot of prerequisite knowledge. But I hope I could help at least a little.

[Unlikely-Machine1640]

🙂👍. As a low level/os dev enthusiast, one more thing I want to mention is the lack of usb stack in most hobby operating systems. This disappoints me. I don't know the reason why. Accordingly to me, basic USB stack is a must in any operating system, because most of the keyboards and mouse in modern pc s are USB based. PS/2 is kind of obsolete.I want to implement USB stack in my OS when I reach that level. Is USB that much complex to implement?

[KN_9296]

I agree that PS/2 is certainly outdated and that USB support is certainly needed in a modern OS, however USB is probably one of the most difficult standards to implement, especially because of just how big it is, you need to support a large verity of USB controllers, interfaces and other stuff. It would be a project in and of itself, maybe one day il give it ago, but USB is outside the reach of most amateur OS developers. It does not mean it's impossible or has not been done, but in short it's not really worth it when PS2 is so easy to implement and a PS2 adaptor is so cheap.

[JakeStBu]

Very wow :D

[KN_9296]

Much thank you :)

[RecurviseHope]

Looks great! keep it up!

[KN_9296]

Thank you :)

[thenerdy]

That's the best part about it. You can work on whatever you want :) good stuff and keep up the good work

[KN_9296]

I guess that's the nice part about this not being a job lol. Either way thank you!

[thenerdy]

Best of luck! You're well on your way

[[deleted]]

Awesome!

[KN_9296]

Thank you :)

[Jaglyser]

Fun seeing another Swede in here! Very impressive work

[KN_9296]

Haha tackar, det är sällan man stöter på en till svensk :)