-
Notifications
You must be signed in to change notification settings - Fork 659
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Tracking: Make Tock Architecture Agnostic #985
Comments
/cc @dverhaert |
To get this going I took a first pass stab at what an interface might look like that an architecture needs to implement to support a syscall interface between processes and the kernel: Lines 23 to 43 in ea39ca7
Please comment or add commits as needed. My goal was not to copy the exact interface we are using now. There is also this issue of the |
This motivated me to resurrect a branch I had lying around towards a Tock native port ( https://github.com/tock/tock/tree/native-port ) -- its fairly immature (currently it'll get as far as segfaulting when it tries to panic from the first of many [Update: Now it'll make it as far a I'll try to see what implementing this interface for a non-MCU case looks like, which hopefully will be a good stress test of its flexibility. |
I got started on this on the https://github.com/tock/tock/tree/arch-agnostic2 branch that builds off of the change to add a From what I posted before:
|
Each process needs a way to keep around architecture-dependent state when that process is not running (for cortex-m we save a bunch of registers). This means the |
Templating pub struct Process<'a, S: SyscallInterface> { ... } and since the /// Main object for the kernel. Each board will need to create one.
pub struct Kernel<S: SyscallInterface> {
/// How many "to-do" items exist at any given time. These include
/// outstanding callbacks and processes in the Running state.
work: Cell<usize>,
/// This holds a pointer to the static array of Process pointers.
processes: &'static [Option<&'static mut Process<'static, S>>],
} but now anything that holds a kernel pointer must also have that template, which is fine except that /// Userspace app identifier.
#[derive(Clone, Copy)]
pub struct AppId<S> {
kernel: &'static Kernel<S>,
idx: usize,
} The issue becomes that Is there a way to avoid this? Maybe some rust trick or some way to structure this that isn't popping into my head? |
This is also true for MPUs -- each process will need to store state on how to restore the MPU when it's switched in. That state is chip-specific (e.g., the state kept for the K66 MPU is different than the standard CortexM MPU). |
1113: Move architecture-dependent syscall code to arch/cortex-m r=bradjc a=bradjc ### Pull Request Overview This pull request moves all of the code that is cortex-m syscall specific out of process.rs and into the cortex-m crate. This is part of #985. It does this by: - Making a new `SyscallInterface` trait that is implemented in the cortex-m crate. Each process has a reference to the implementing struct. - Making a new `ProcessType` trait that all process types implement (right now we only have one, `Process` in process.rs). This allows the `Process` struct to be templated over the `SyscallInterface` type while the `processes` array in the `Kernel` struct keeps an array of `ProcessType` implementations: ```rust Kernel { processes: &'static [Option<&'static process::ProcessType>] } ``` which means the template parameter stays only in the process.rs file and does not spread to all of Tock. The panic! prints in process.rs are partially commented out because they relied on many architecture-specific fields. Also the `SCB_REGISTERS` global static variable still exists. Moving those to the cortex-m crate is forthcoming in a different PR. This is blocked on #1111. ### Testing Strategy Hail on Hail, but needs more. ### TODO or Help Wanted n/a ### Documentation Updated - [x] Updated the relevant files in `/docs`, or no updates are required. ### Formatting - [x] Ran `make formatall`. Co-authored-by: Brad Campbell <bradjc5@gmail.com> Co-authored-by: Pat Pannuto <pat.pannuto@gmail.com>
Should we move the tock/kernel/src/platform/mod.rs Lines 19 to 33 in a2c3347
I think this is cleaner, as there is really no reason the board file should have to pick a chip and an arch. This board file then looks like: Lines 591 to 601 in a2c3347
The full implementation is here: https://github.com/tock/tock/compare/new-mpu-new-chip?expand=1 |
1159: New MPU Interface r=bradjc a=dverhaert ### Pull Request Overview This pull request introduces an updated MPU interface that is no longer Cortex-M4 specific. It follows up on #1126, being part of a plan to make Tock architecture-agnostic (#985). An overview of the key differences: 1. The interface now has two Tock-specific functions for allocating and updating the MPU region for the app-owned portion of its RAM. 2. The interface now only supports specifying user permissions for regions (instead of also specifying supervisor permissions). Memory locations not within any allocated region are required to be inaccessible in user mode, and accessible in supervisor mode. A related change is that we no longer allocate an MPU region for the grant memory in process.rs. 3. Instead of reallocating all the MPU regions every context switch, regions are now only allocated (computed by the MPU) when they are created or updated. Configuration of the MPU registers is now the only thing that happens during context switches. The main reasoning behind the first decision is that the app break grows over the lifetime of the process. As such, we have found it infeasible for the client to request an MPU region that is suitable for this purpose through a generic region request. The reasoning behind the second decision is that allowing simultaneous specification of both user and supervisor permissions necessitates exposing a large matrix of options that no single MPU is able to support. When decoupled, we are left with a small, logical set of user permissions that we can reasonably expect all MPUs to be able to support. Furthermore, it is more consistent with our current practice of only enabling the MPU for processes. The new interface allows removal of code from process.rs that assumed the presence of the Cortex-M MPU, and in particular its constraints and features. For instance, in the Cortex-M, the size of an MPU region must to be a power of two and aligned to the start address, and in the case of region overlap, the permissions of the overlapped segment are those of the region with the highest region number. For further background and discussion, see the relevant [thread on tock-dev](https://groups.google.com/forum/#!topic/tock-dev/Fduxk_0xvUE). If something remains unclear, feel free to leave a comment below. ### Testing Strategy This pull request was tested by running the `mpu_stack_growth` app in libtock-c, as well as a few others: one that walks over a process's RAM and flash regions, and several that try to make invalid accesses outside of these regions. ### TODO or Help Wanted - [ ] **Fix `_start` in userland**. @alevy is working on a [branch](https://github.com/dverhaert/libtock-c/tree/fix_start_order) in libtock-c that fixes `_start` so that processes never access memory past their app break. This pull request is blocking on that branch being merged. - [ ] **Loading processes**. Ideally we would load processes in decreasing order of RAM size on boards that use the Cortex-M MPU. Doing so would eliminate the possibility of external fragmentation between processes on such boards. - [ ] **Size of the `mpu_regions` array**. This field in `struct Process` is currently hard-coded to be 6 in size because the Cortex-M supports 8 regions (and two of these are reserved for the flash and RAM regions). This is the last architecture-specific code remaining in process.rs. It currently seems infeasible to make this size chip-specific, seeing as [Rust doesn't seem to support this yet](rust-lang/rust#43408). ### Documentation Updated - [x] Updated the relevant files in `/docs`, or no updates are required. ### Formatting - [x] Ran `make formatall`. Co-authored-by: Conor McAvity <cmcavity@protonmail.com> Co-authored-by: Brad Campbell <bradjc5@gmail.com> Co-authored-by: Danilo Verhaert <daniloverhaert@gmail.com>
Ok! For the first pass this is done. We have to actually try to use Tock on a new architecture to really evaluate this, but all of the goals for this issue have been met. |
Since we only currently support Cortex-M class devices it hasn't been a problem to have cortex-m specific things in the kernel crate. However, our longer terms goals require that the kernel crate be architecture agnositic.
Process
across architectures. (Move architecture-dependent syscall code to arch/cortex-m #1113)PROCS
variable. (Kernel: MovePROCS
array toKernel
struct #1111)The text was updated successfully, but these errors were encountered: