Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
New MPU Interface #1126
Pull Request Overview
This introduces an updated MPU interface that is no longer Cortex-M4 specific. The
This PR represents a first step in a plan to create an architecture-agnostic interface to isolating process memory (e.g. using the CortexM's memory protection unit). During the design process, we realized that, at a high level there seems to be a trade-off between an interface that is simple to implement (for each architecture) and use (for
There's a thread on Tock Dev with discussion of some design considerations.
This step represents a first attempt to optimize the former. In particular, it requires very minimal changes to process.rs, and the Cortex-M implementation is relatively simple.
This will serve as a benchmark to measure future designs against: how much more complicated does an efficiency-friendly interface make implementations? is it worth it? etc.
TODO or Help Wanted
@dverhaert and I are currently working on a second version of this interface that, among other things, reduces the overhead during context switches by disentangling allocation of regions from switching to a region configuration (thus removing allocation from the hot path in
@phil-levis I'm personally open to both.
Aside from reviewing in detail, I think this represents a significant improvement over our currently hyper Cortex-M specific interface.
Importantly, it allows @cmcavity to implement the interface for the MK66 and finally make the Teensy a first-class supported board (which has basically been blocking on not having a supported MPU). It also serves as a benchmark to actually evaluate the design changes proposed on the tock-dev thread, as well as alternate approaches.
Meanwhile, making the rest of the kernel architecture agnostic is chugging along.
On the other hand, if the feeling is that this interface is bad in a way that a future version near to come will strictly improve upon, it also seems perfectly fine to have this PR sitting around just as a marker of progress for the rest of us.
I think we want to only change the MPU interface once; if I were supporting an out-of-main MCU with a different MPU, I might be willing to implement it once if it meant I could then get protected processes, but would be pissed and frustrated if I had to do it twice in the space of a few months.