You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I think I have newproc and sleep/wakeup working. I could be wrong.
sys/machdep.c has the starts of a promising technique of writing .S code naturally inlined to C.
main.c seems to be calling newproc successfully,. The copyout() that puts the init skeleton into user space is being called, but probably not with a real, suitable executable.
I've put in a moderate amount of scaffolding to prop up user space, but we still need to connect the ECALL handler to something that connects to sysent[] from the generated trap.
This is kind of the intersection of several sketched in components that aren't really tested.
Since we don't really have VM (unless we raise the hardware requirement to a device that support RV39) we'll have to think through what we want our memory map to look like and how to share kernel and user space (probably meaningless terms w/o MMU) to at least minimize the risk of them trampling each other.
We also have the landmine that the x86 port, whence this code came, hardcoded page numbers in several places that I've removed. Some surely remain. "We don't know what we don't know."
The text was updated successfully, but these errors were encountered:
I think I have newproc and sleep/wakeup working. I could be wrong.
sys/machdep.c has the starts of a promising technique of writing .S code naturally inlined to C.
main.c seems to be calling newproc successfully,. The copyout() that puts the init skeleton into user space is being called, but probably not with a real, suitable executable.
I've put in a moderate amount of scaffolding to prop up user space, but we still need to connect the ECALL handler to something that connects to sysent[] from the generated trap.
This is kind of the intersection of several sketched in components that aren't really tested.
Since we don't really have VM (unless we raise the hardware requirement to a device that support RV39) we'll have to think through what we want our memory map to look like and how to share kernel and user space (probably meaningless terms w/o MMU) to at least minimize the risk of them trampling each other.
We also have the landmine that the x86 port, whence this code came, hardcoded page numbers in several places that I've removed. Some surely remain. "We don't know what we don't know."
The text was updated successfully, but these errors were encountered: