kmi/arch/riscv/config.h, branch masterACTIVE - Kernel with migrating threads as IPChttps://metanimi.dy.fi/cgit/kmi/atom?h=master2022-01-07T12:05:06ZAllow building with clang2022-01-07T12:05:06ZKimplulkimi.h.kuparinen@gmail.com2022-01-06T21:39:12Zurn:sha1:9cc125fb3cfdc2c8ae7153b5ae0fe705980835fb
+ Release mode is sort of broken, as lto doesn't work with linker
relaxation and turning the relaxation off causes issues with the jump
from init to kernel (as I've currently implemented it, could probably
be fixed with a manual jump from assembly, I'll add it to my TODO
list)
Refactoring2021-12-29T21:53:06ZKimplulkimi.h.kuparinen@gmail.com2021-12-29T21:23:36Zurn:sha1:4f4d9fdc89c27aa3346467a24b621954f4564d3b
+ Mainly just moving stuff out or arch/riscv/ that should be handled in
common/
+ Prepared separate process stack/call stack for server callbacks, rest
to be implemeted soon ish
Right up to init_proc, FUCK YEAH2021-12-20T19:03:37ZKimplulkimi.h.kuparinen@gmail.com2021-12-20T19:03:37Zurn:sha1:61291639524e4aebf93a3315661e7180ac1b9c1e
+ Lots to do still, should keep a more detailed TODO.txt, among other
things implement Sv48 support, make more things single truths etc.
More sensible init2021-12-20T12:53:44ZKimplulkimi.h.kuparinen@gmail.com2021-12-20T12:53:44Zurn:sha1:6f8e5772d17d277842be3f6162ddd665a17e5be9
+ Who knew some reservations were a good thing? (at least relativelyy
speaking)
Some minor changes to virtual memory handling2021-10-25T16:44:11ZKimplulkimi.h.kuparinen@gmail.com2021-10-25T16:40:53Zurn:sha1:7f7b3d61baf46fe358d3f1bd1cb584e0daed3a81
+ Should start to think about how virtual memory should be handled
efficiently, I'm sort of flailing around and not actually doing
anything beneficial. The mapping system I've so far implemented
_works_, but it's not good and I'm not happy with it. I might come
back and fix/improve it, but I think I'll go ahead and do other things for
a while, might give me a better overhead view of what the virtual
memory system should do.
+ TODO: should probably document the memory layout I'm going with at the
moment.
Start designing vmem framework2021-10-11T20:18:47ZKimplulkimi.h.kuparinen@gmail.com2021-10-11T20:18:47Zurn:sha1:7237d673904d8568a2f9c290a0247c9d1a07c5d2Prepare proper jump to kernel2021-10-10T20:03:20ZKimplulkimi.h.kuparinen@gmail.com2021-10-10T20:03:20Zurn:sha1:d2ff961a2a08229e1f2245e8dba9b2275016133cFirst jump to virtual memory!2021-10-01T17:36:15ZKimplulkimi.h.kuparinen@gmail.com2021-10-01T17:36:15Zurn:sha1:b30ee14270a44e48167934b9b3923b4280bdc855
+ Lots of bughunting to do, probably lots of off-by-one and so on
errors, and I make a lot of naive and possibly dangerous assumptions.
But cool start nonetheless. Should also come up with some method of
exchanging data between the init and actual kernel, probably some struct
of some sort. TODO
Used memory regions now marked2021-09-25T11:56:43ZKimplulkimi.h.kuparinen@gmail.com2021-09-25T11:56:43Zurn:sha1:2d173beb3392aff35c8a33f4ac001bf63bb9adc6
+ I don't fully trust my memory management system yet, so should
probably check the memory regions it gives.
Added default stack location2021-09-25T09:24:24ZKimplulkimi.h.kuparinen@gmail.com2021-09-25T09:24:24Zurn:sha1:13fe461374c0716404e2ee7726781b9cd12dbaa7