Hi Lawrence, Thanks for posting this! Apart from the other posts, I wanted to briefly summarize the next steps we discussed on the core call on Friday, the notes of which are up in a PR [1]. There are three types of changes to the system call interface that we'll have to think about for supporting a CHERI and/or 64-bit platform: 1. The system call driver return values. Possible changes are to - extend the `SyscallReturn` enum with additional variants. We'll have to make sure that we did not promise this enumeration to be exhaustive in our documentation (likely TRD104) and ensure that none of our current userspace libraries rely on the current enum definitions to be exhaustive. We can likely implement this in a TRD that extends TRD 104, and as part of a minor version bump. - change certain system call's return values, to better match the semantic meaning of their return value and to avoid switching between variants on different platforms. For this change to be rolled out on 32-bit platforms, we'll need to wait for a major (breaking) release. Depending on where this is documented, we probably want a full revision of TRD 104 and other applicable reference documents for this. 2. System call arguments. Driver and subdriver (command number) arguments should always be 32-bit. We should check if we state something different anywhere, and then manifest these changes in the kernel code base. Notably, libtock-rs already assumes them to be u32s. For the two command arguments, we need to decide whether we want to encode more typing information into a driver's interface. Currently, these arguments are `usize`. We very much intended these to be only `u32`s (such that driver interfaces are identical across platforms). The kernel still uses `usize` for these as we didn't want to change interfaces when practically, given we only supported 32-bit platforms, these types were identical. It is clear that restricting these to `u32`s will be prohibitive of some applications, such as passing length parameters over this interface. However, we'd probably still want to document and enforce which type a driver actually expects to be passed as a parameter. One such soltion would leave the raw interface types as `usize`, but extend a proposal like https://github.com/tock/tock/pull/4112 to add type information per command-number and implicitly cast this `usize` per sub-command. 3. Upcall parameters. Upcall parameters should be able to return buffer lengths, etc. Therefore, they also should be `usize` wide. TBD: do we want more typing information here? It seems harder to enforce the relation between upcall-number and types passed. Maybe we can extend the Grant type to encode this information? In summary, we'll likely want to review these interface changes as part of either a minor extension or revision of TRD 104, to ensure that we stay backwards compatible. A full interface revision can then be proposed as a full TRD. Finally, I want to echo Hudson's and Johnathan's statements from the call: as long as we don't change the existing 32-bit non-CHERI interface, it should be fine to introduce a new ABI for these new platforms. However, we want to make sure that this doesn't cause much overhead or churn for kernel & capsule developers. This interface should probably also be proposed in a TRD. It seems best to continue figuring out these open questions and details on the mailing list. Hope this summary is useful! I hope I didn't mischaracterize anyone's opinion, please let me know if you disagree with anything. -Leon [1]: https://github.com/tock/tock/pull/4189