| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
|
|
other parts of the kernel don't need to care about which process exactly
gets switched into
|
|
this makes `process_transition` safe again, as it won't be able to free
processes. it was a pretty unintuitive behaviour
|
|
|
|
|
|
|
|
handling the backend queue makes more sense here than in the syscall
implementation. it's also just overall cleaner
|
|
|
|
|
|
|
|
|
|
removes `proc.c`'s pointless dependency on `vfs/root.h`
|
|
|
|
|
|
|
|
the loop wasn't bounder, so was copying garbage - including multiple
null bytes
also, the trailing slash was appended even if the injected path didn't
have one
|
|
|
|
|
|
this currently crashes the kernel. the point is to stop it from doing
that
|
|
|
|
|
|
|
|
|
|
|
|
|
|
thanks to this it's easier to power off - instead of waiting for all
processses to quit (which now involves writing `quit` both on serial and
ps/2), one of those can just somehow kill init.
currently this is just done by exiting from any shell - init will return
from await and exit too
|
|
|
|
|
|
|
|
|
|
proper multiprocess support!
|
|
first off: this is horrible. there's no CoW, so this is horribly slow.
the sole purpose of this is to let the userland delegate handle multiple
requests at once, because i'm implementing concurrent IO and I kinda
need that.
it's possible that handling of multiple requests could be handled in a
better way - but this could be good enough once i implement CoW
|
|
|
|
|
|
|
|
i was disabling it while working anyways, i'll only turn it back on once
there's support for multiple processes waiting for an irq
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
