ACTIVE - Kernel with migrating threads as IPC https://metanimi.dy.fi/cgit/kmi/atom?h=master 2024-07-17T16:34:03Z 2024-07-17T16:34:03Z Kimplul kimi.h.kuparinen@gmail.com 2024-07-17T16:34:03Z urn:sha1:83f8e82c421fa9013ac813b1560abf1c749822ca 2024-07-09T19:12:27Z Kimplul kimi.h.kuparinen@gmail.com 2024-07-09T19:12:27Z urn:sha1:e8a1df103cc28419dd7d4439c0b1d1739d110f78 + Current setup will likely not last long, just a stopgap until I figure out how I want to build each testcase etc. Probably dir based, but I'll probably add some scripts that generate the build rules for each test case (or binary?). Also, should probably put ouput files in a build directory and keep the source clean, but again, good enough for now. Will have to start implementing more extensive tests, and probably come up with some way to compare textual output etc. 2024-07-09T16:24:12Z Kimplul kimi.h.kuparinen@gmail.com 2024-07-09T16:24:12Z urn:sha1:89d7cf197b2cae130565467bdfad5d5ef5fed2dd + A reserved area is an area at the start of the region that should not be used unless explicitly asked for, for example null pages. As such, a small correction to my previous commit message: There's no danger in not locking req_mem() etc, as a null page will only be allocated when explicitly asked for. 2024-07-09T14:35:56Z Kimplul kimi.h.kuparinen@gmail.com 2024-07-09T14:35:56Z urn:sha1:298636079d912d0936f8156a609fe74b839c547b + User has to 'free' the 0 page before it becomes accessible to mapping. Probably worth noting that this is likely VERY niche and mainly concerns stuff like certain kinds of emulators that I'm still eons from implementing, but still. Unbacked pages can also be useful for some kinds of notifications, like 'if someone writes to this page, please report it to me with this ID' or whatever, I remember seeing some discussion about it somewhere but that's also not really relevant for the moment. Most significantly, at least with the current design, after the null page is freed it becomes available for use to regular req_mem() calls, so users should probably using locks around memory requests. That's probably a good idea anyway as internally the kernal has to lock the virtual memory, and without a scheduler it might cause threads to spin for a while in the kernel which is rather bad. 2024-07-08T15:04:03Z Kimplul kimi.h.kuparinen@gmail.com 2024-07-08T14:43:59Z urn:sha1:e134202611a50b358c147c92bfb8a7f443030b8b + Anything extern is right out as LLVM doesn't produce correct code for them. Maybe if I added some extra attributes but I'm skeptical. Replaced with static variables and getters/setters. + Inline ASM is apparently a bit buggy, so use an assembly stub when jumping to init. + Minimize work done in main() to minimize chance of LLVM doing something silly. Still not 100% certain that I shouldn't just write the main() as an assembly stub in arch/riscv64 to be absolutely sure everything works as intended. + Make .kernel.start section SHF_ALLOC, otherwise lld complains about pc-relative addressing Probably some other stuff as well that I'm forgetting right now. But at least with LLVM14 LTO seems to work, which is pretty cool? 2024-07-07T18:47:14Z Kimplul kimi.h.kuparinen@gmail.com 2024-07-07T18:47:14Z urn:sha1:219c27d420fe0abe5515cefc2513c6fe60aafdf9 + Can be used to pass contiguous memory regions to things like virtio block devices for implementing disk drivers etc. 2024-07-07T15:12:55Z Kimplul kimi.h.kuparinen@gmail.com 2024-07-07T15:12:55Z urn:sha1:fe4c623cb9320226866829317cea8ba0c49e7dbc + Effectively means that all executables can be called into, but if an exe doesn't want to deal with anyone else it should just set a flag like `not_really_a_server` or whatever 2024-07-07T11:34:39Z Kimplul kimi.h.kuparinen@gmail.com 2024-07-07T11:34:39Z urn:sha1:d592abd8ccc4026c51e196777031eb65c4acc4de + Align kernel to 2MiB boundary in u-boot + Optimize alignment functions a little bit, should still have to check on real hardware but 'feels' more clean + Add early boot debugging + Put extra cores we aren't ready to account for to sleep if/when they boot. + Make BASE_PAGE_SIZE constant on riscv64/32, helps the compiler with some alignment checks among other things. 2024-07-07T04:02:46Z Kimplul kimi.h.kuparinen@gmail.com 2024-07-07T04:02:46Z urn:sha1:b97967ab660243b723f246db03c2e4a82e125f3f + No real point having multiple different levels of assertions, just say you assert something and be done with it 2024-07-07T04:00:43Z Kimplul kimi.h.kuparinen@gmail.com 2024-07-07T04:00:43Z urn:sha1:122374c362ba8bb9082385da3c82e264ab594f15 + Had some minor issues with a wraparound of size_t that effectively meant that some regions were allocated twice. Also, booting should be a bit more reliable now, turned out that the previous iteration of the booting was just accidentally working due to the kernel being placed 'close enough' in RAM to where it was linked to. Fixed by allocating a vmem of O1 that maps the kernel to a 2MiB boundary at boot, pretty nifty.