| Age | Commit message (Collapse) | Author |
|---|
|
+ 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
|
|
+ Lots to do still, should keep a more detailed TODO.txt, among other
things implement Sv48 support, make more things single truths etc.
|
|
+ Who knew some reservations were a good thing? (at least relativelyy
speaking)
|
|
+ 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.
|
|
|
|
|
|
+ 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
|
|
+ I don't fully trust my memory management system yet, so should
probably check the memory regions it gives.
|
|
|
|
+ Will probably still need a fair bit of tweakind and documentation
improvements, but seems to work outside of the kernel. Also no valgrind
errors, which is quite promising I guess.
|
|
At least as far as reading memory info, cool.
One issue I have is that .(ro)data is apparently accessed by absolute
addresses, so I need to know at which address the kernel is going to be
loaded. I would prefer completely position independent code, but if
that's not possible then eh.
|
