General Comments about wasi-libc HOT 1 OPEN

Each syscall should ideally have its own entry point. Contrast this with one big syscall entry point where the host implementation must switch on a syscall number.

Let's be explicit about what the advantages are. Some are:

• static analysis can determine which syscalls an application may use, which may be useful for auditing, dead-code elimination, debugging
• it avoids the need for a big switch on the callee side, which may make it more efficient

Using a single syscall with a number has some advantages too:

• It's simpler to proxy to other places (eg. proxying synchronous I/O syscalls to the main thread from workers in a browser), or to log, in a generic way
• It's simpler to add new system calls and let user applications dynamically test whether they're supported.

Relatedly, each syscall entry point should have a unique signature. For instance, emscripten currently passes a pointer to a struct that contains the arguments for each system call. This incurs overhead since the host implementation has to copy the arguments to its stack and also check if the user pointer overflow.

My understanding is that this makes it possible to reuse more of musl's code directly. But you're right that it's more efficient, less error-prone, and overall simpler to use specific signatures.

I think errno should live at a higher level. Syscalls simply return -errno to signal error. Non-negative return values flag success.

I think that will be uncontroversial :-). Another option to consider though is to use multi-value returns, giving syscalls an extra return value to indicate errors. This can make things more consistent in the case of syscalls that aren't otherwise returning non-negative signed integers.

mmap() may require special consideration.

Yes, mmap is a very special case from numerous perspectives :-).

Part of mmap's functionality may even need to be a WebAssembly feature, rather than just an import. See some discussion here for example.

from wasi-libc.