| Age | Commit message (Collapse) | Author |
|
+ Slightly unsure if it should be a syscall, or if assign would be
enough. Also, which thread should run in a fork/spawn? For now, old
thread, though this might increase latency. Or add swap flag to these
calls?
|
|
|
|
|
|
+ In total, a syscall is built up of 6 values, with the first being the
syscall number. Symmetrically, the first value is now a status and the
following five values return "values". This allows us to cram in more
info into the ipc_* functions. The performance difference is
absolutely minimal, at least from my testing in qemu.
|
|
|
|
+ Note that it is NOT intended for end user usage, just for debugging.
|
|
|
|
|
|
+ Prepare for possibly testing rv32
+ Also remove newline from debugging output
|
|
+ May warn about PHDR not being in LOAD, there is a flag to silence it
(--no-warn-rwx-segment) but it doesn't seem to exist in
riscv64-unknown-elf for some reason.
|
|
+ Doesn't seem to be specified anywhere, but I'll stick with 2MB for
now, working on the assumption that the FW is at the start of the
physical RAM.
Possible TODOs: generate apos.its automatically from init.elf,
allocate root_branch statically?
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
+ Essentially, separate root process and remote procedure call handling.
I really should write down some documentation so I don't forget, but
essentially: All threads share a common process virtual memory, and
when a thread wants to make an rpc, it switches over to its own rpc
vmem space that is linked to the remote process.
|
|
|
|
|
|
|
|
|
|
|
|
The output is close enough, and I like that uncrustify is a third-party
tool, so people can install a single tool for formatting instead of
having to lug around a whole toolchain. I fully expect to have to add
settings to uncrustify.conf, but let's see how this goes.
|
|
|
|
+ Next step, start documenting contents of each file.
|
|
+ Closer to what it's for rather than what it is.
|
|
|
|
+ next up would probably be to start working on process/thread
relationships, largely as documented. Still not entirely sure about
how I want to handle fork, but I suppose I might figure it out at some
point.
|
|
|
|
|
|
+ Doesn't quite compile all the way unfortunately, building the GNU toolchain on NetBSD is a bit more difficult than I was expecting. LLVM does compile, but fails to link for some reason.
|
|
|
|
|
|
|
|
+ Still lots todo, and I'm not entirely sure how I should handle program
space switches (mainly since the kernel uses the process' stack, maybe
it shouldn't?)
|
|
|
|
+ Will most probably not work on 32bit, but nice to make 'portable'
code.
|
|
+ GCC seems to provide this even on 32bit platforms, though I should
really check.
|
|
|
|
|
|
|
|
|
|
lower 8 bits are reserved for arch-specific flags (but at least
read/write/execute) and higher 8 bits are metadata, currently only for
VM_VIRTUAL (to be used when the backing physical memory shouldn't be
freed)
|