| Age | Commit message (Collapse) | Author |
|
+ Start out using big kernel lock, apparently seL4 thinks its good
enough. I might have a go at using a more fair lock, and possibly
moving to more fine-grained locks if I really feel the need to get
scalability up.
|
|
+ Fairly considerable speedup, as we don't have to look up the rpc pte
every time separately, instead cacheing them. Adds an architecture
specific limitation to total rpc stack size, though.
|
|
|
|
|
|
|
|
|
|
|
|
+ CSR_STVEC requires four byte alignment
|
|
+ RELEASE=1 doesn't work for some reason, though
|
|
|
|
|
|
+ Eliminated need for save/load_regs, now the register save area is
behind a pointer which _slightly_ increases overall syscall delay, but
speeds up ipc requests by a fair bit.
|
|
|
|
|
|
+ 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.
|
|
|
|
|
|
|
|
|
|
|
|
+ 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.
|
|
|