I don't think (2) is acceptable in Tock 2, because it would be a breaking change. However, I don't think we need to add as many new return variants as (1) proposes. I don't think we care about any platforms where address offsets may exceed 2 GiB (correct me if I am wrong), so we can pack offsets into i32/u32 even on our 64-bit platforms. Therefore, I think the only return variants we need to add are: 1. SuccessWithMetaPtr: Used by Memops 1-9. 2. SuccessWith2MetaPtr: Used by Subscribe and all three Allows. 3. FailureWith2MetaPtr Used by Subscribe and all three Allows. We would keep the current return variants for all currently-stabilized system calls on 32-bit non-CHERI platforms, and use the new return variants on all other platforms (including all 64-bit and CHERI). That keeps backwards-compatibility on platforms that Tock 2 currently supports while providing better semantics on 64-bit and CHERI platforms. For Tock 3, it might make sense to go somewhat further than just u32, u64, usize, and MetaPtr. How about signed integer, floats, bool, etc? It would be nice if the system call layer could indicate that the button upcall <https://github.com/tock/tock/blob/65dda58c893e5b1fb49da7e4389552584758d5e1/doc/syscalls/00003_buttons.md#subscribe-number-0> receives a (u32, bool) and the temperature reading upcall <https://github.com/tock/tock/blob/65dda58c893e5b1fb49da7e4389552584758d5e1/doc/syscalls/60000_ambient_temperature.md#subscribe-number-0> receives an i32 (this isn't in the documentation), rather than pretending that all upcalls receive (u32, u32, u32). On Thu, Oct 3, 2024 at 3:51 PM Amit Levy via Devel <devel@lists.tockos.org> wrote:
The current set of return codes include a type. e.g. calls like allow/brk currently return SyscallReturnU32U32 or SyscallReturnU32. Clearly this is not true for 64-bit platforms. Or for CHERI where the size of an address is not the size of a pointer.
Excellent point, and this is definitely something to address. Thanks for noticing and bringing this up.
I think given this is in the context of switching from only 32 support to adding 64 bit and/or CHERI, I don't think we should be overly concerned about breaking backwards compatibility. Instead, this is potentially a fine reason to think towards a 3.0 system call interface---one which shouldn't be overly difficult to port to, but wouldn't be binary compatible with applications compiled for 2.0. (we may lump in fully relocatable binaries and/or first-class non-XIP support if changing some expectations about binaries helps us accomplish that, as as potentially changes to core system interfaces, such as IPC)
From that perspective, I think (1) is untenable. I think we should be much more concerned with portability of, e.g., capsules and a unified system call interface than with backwards compatibility. I don't think there is any advantage to (1) other than backwards compatibility.
I think (2) is the answer. It follows the general idea in the MetaPtr PR (#4174) of converting naming things what they actually are.
(3) I understand the expediency for a downstream port, but I don't see an advantage to this if we can do 2 (which I think we can).
(4) Similar to 3. I think it would be _reasonable_, if we went with 3, to bump the major version number and redefine "success" to have the current value of successu32, such that it just happened to be the case that 2.0 binaries also turned out to work unmodified.
-Amit _______________________________________________ Devel mailing list -- devel@lists.tockos.org To unsubscribe send an email to devel-leave@lists.tockos.org