I think this is a good discussion for Friday, but I wanted to send out an
advance email to give time for people to gather their thoughts in advance
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.I think there are a few options:
1. 1) They should return different codes on different platforms:
SyscallReturnu32 on 32-bit, SyscallReturnu64on 64-bit,
SyscallReturnMetaPtr on CHERI etc with some meta constructors to help
choose. Userspace should expect the same and be If-Defed appropriately.
2. 2) They should return a new more specific code SyscallReturnPtr /
SyscallReturnUsize on all platforms, and user space should check for
just that one.e
3. 3) These calls are already made type safe because of the wrappers in
libtock-c / libtock-rs. Just use SyscallSuccess for these built in
syscalls. Wrappers know what they are getting.
4. 4) A true evil one. Option 3, but SyscallReturnu32 is the code for
legacy reasons. You know what you are actually getting.
What I actually did on my fork was just 3 (because all these different
codes were getting in the way), but this does break compatibility unless
there is a matching change in libtock-c/libtock-rs and it would probably be
better not to do so. In fact, both 2 and 3 are breaking API changes. This
means that possibly we should prefer (1), simply for backwards
compatibility? This is roughly what the consttructor I added for
SyscallReturnUsize does: selects one of SyscallReturnu32 or
SyscallReturnu64 as appropriate. But possibly we will need a few more as
soon as CHERI comes into play.As for types for commands:Currently in the
kernel commands are:fn command(&self, cmd_num: usize, arg1: usize, arg2:
usize, appid: ProcessId)
Which is already usize-ified.In libtock-c: syscall_return_t
command(uint32_t driver, uint32_t command, size_t arg1, size_t arg2);
There is clearly a mismatch there on command number. I am of the mind that
the driver/command being u32 is fine, and args should really be usize. For
instance, a command might realistically take an offset to a previously
allowed buffer. This is usize, not u32.Upcalls: in the kernel were all u32,
I changed most of the arguments usize apart from data/fn pointer which are
MetaPtr. i.e., the type in C should be:typedef void
(subscribe_upcall)(size_t, size_t, size_t, void*);where currently it istypedef
void (subscribe_upcall)(int, int, int, void*);And I think its worth some
discussion whether people are happy with this. It means nothing for 32-bit
libtock-c because the ABI for passing usize is the same as int on 32-bit
platforms. In libtock-rs I have the patches ready to go to define the
upcall trait on both u32 and usize so it won't break any code there.
Lawrence
