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
In xv6, code path for trapping into user-space and back is really confusing. Typically this is done with:
forkret() -> usertrap() -> making syscalls, etc. -> usertrapret()
I've encountered the issue of RAII. As we call usertrap in forkret, any object created in forkret won't be dropped as usertrap won't return.
Previously I thought this could been done by introducing a return_to function, in which RISC-V return address register ra is rewritten with the address of that function. For example,
fnforkret() -> NeverReturn{return_to(usertrap)}
Therefore, object can be correctly dropped before jumping to usertrap. However, there're many issues with that.
After that, I propose to use a k_thread() function to represent full code path for trapping into and returning from user-space.
func k_thread(){// forkret contentsloop{// usertrap contentsawait_into_userspace();// A function calls into user space and returns on trapif scause == timer {yield();}syscall();// usertrapret contents}}
And the scheduler just schedules those k_threads, which solves the RAII issue.
Furthermore, I would like to have this issue solved with async-std crate, which supports no-std environment.
The text was updated successfully, but these errors were encountered:
In xv6, code path for trapping into user-space and back is really confusing. Typically this is done with:
forkret()
->usertrap()
-> making syscalls, etc. ->usertrapret()
I've encountered the issue of RAII. As we call
usertrap
inforkret
, any object created inforkret
won't be dropped asusertrap
won't return.Previously I thought this could been done by introducing a
return_to
function, in which RISC-V return address registerra
is rewritten with the address of that function. For example,Therefore, object can be correctly dropped before jumping to usertrap. However, there're many issues with that.
After that, I propose to use a
k_thread()
function to represent full code path for trapping into and returning from user-space.And the scheduler just schedules those
k_thread
s, which solves the RAII issue.Furthermore, I would like to have this issue solved with
async-std
crate, which supports no-std environment.The text was updated successfully, but these errors were encountered: