Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Implement `UserspaceKernelBoundary` version 2 #1318
Pull Request Overview
This pull request is the answer to the question we had a while ago of "Are we confident in the
After working on RISC-V context switching, it is clear some of the interface does not map to RISC-V very well. To make
This PR also includes a patch to the cortex-m arch to support the new version of UKB.
The major change is that we no longer remove the SVC stack frame after a yield call. In fact, the API for popping stack frames has been removed. Instead, when we want the process to run a new function, we re-use the old SVC stack frame. In the case that the app has never run before we do have to create the stack frame just like we used to.
In theory, this is actually more efficient since we save the effort of removing the stack frame, but that wasn't very substantial so who knows.
The other change is we now set
This pull request was tested by running a few apps on hail. Given what happened last time I started messing around with this code, more is needed....
TODO or Help Wanted
We can probably wait to merge this until after context switching is fully working for RISC-V. I think these changes will be sufficient to support RISC-V, but there may be more that is needed. I did want to get this code in front of people, however, since it touches some low-level kernel features.
I think it's a bit weird to include
I did leave the
(tested with the basics: blink/c_hello/hello_loop; worked fine)
Well, we use it in the RISC-V implementation as well as there is a architecture-independent difference between the starting an app for the first time and resuming an app because only in the latter case does it have any state on the stack or in registers. However, I think only the kernel knows this, and as such needs to pass it to the UKB implementation. What happens in your implementation if an app is restarted?
Hmm, so, my thinking here is definitely influenced by having just read the HotOS fork paper, but I'm wondering if the idea of (literally) restarting a process isn't a good one. It means that we would have to implement code that is able to correctly undo everything a process has ever done to its kernel state, which feels complicated and hard to get right.
I think it architecturally makes more sense to implement "Restart" behavior by completely tearing down the old process and then creating a new one, rather than trying to re-use anything.
Now, all of this is lives on the enormous caveat that currently we have don't have a way of destroying processes, but they are dynamically allocated at least, so at least half of the hard work is already done. Towards the mission of restart-able processes, I think we should focus effort on implementing tear-down, rather than thinking about code to "restart" an existing process.
To the question then of
Conceptually I think this is a bit nicer as it moves chip-specific process creation to part of the process creation logic rather than having it co-mingled with regular execution.
A side concern with (both) interfaces as-presented is the assumption that the only initialization stuff that will be necessary is stack related. Maybe that's sufficient. I played with a variation that passed a reference to the
I like this interface, and I agree it's better to be explicit about the functionality.
That would make that feature easier to maintain as
Well that function gets