Syscalls

This is implemented in syscalls

The numbers of the syscalls and some metadata like SyscallResult and SyscallError are defined in kernel user link crate.

Syscalls specs is as follows:

• Syscalls can have up to 7 arguments, and are passed in RCX, RDX, RSI, RDI, R8, R9, R10 in order.
• The syscall number is passed in RAX.
• The syscall return value is passed in RAX, the syscall may write to pointers passed in the other registers, but the result code will still be in RAX.
• The returned RAX value is an encoded value of SyscallResult. So, its never intended to be read as u64 directly.
• The arguments are not modified by the syscall, but the syscall may read from them, or write to memory pointed by them.
• All pointers passed to the syscall are have to be valid, and point to user space memory only, the kernel will check that the memory is mapped and write to it, but it doesn't guarantee the validity of the memory if it was modified by the kernel (i.e. if the memory was pointed to random part in the heap it could corrupt the heap for example).
• The syscall may block execution depend on the syscall itself, like wait_pid or a read to a blocking file with no data.

Syscalls list

This shows the list of syscalls and their arguments and return values. Some notes on this:

• a: *const/*mut T, b: usize will be used in the kernel as a slice, for example write(file_index: usize, buf: &[u8]). But I didn't want to remove an argument and confuse the reader, so I split them into two as being sent from userspace.
• types like &Path, BlockingMode, SpawnFileMapping, etc... are passed as u64 as is everything, but the kernel checks validity and cast/parse these pointers/values to the correct types.
• All the return types are SyscallResult and will report any error during execution, for simplicity, I didn't just repeat that in the table.
• When the return type is (), it means the kernel will return SyscallResult::Ok(0), the userspace will check that its 0.