syscall ABI

IIUC we currently don't have a stable syscall ABI. I think we should try to standardize something.

Having a stable ABI we agree on means that embedder don't have to roll their own. There's plenty of experience to gain from what Emscripten did, and I would love to have its JavaScript syscall layer as a free-standing thing.

Here's a quick sketch:

• Each syscall is its own function (unlike e.g. Linux where each syscall signature is a function, taking as first parameter the syscall number).
• Go through the existing syscalls and adopt ones we deem useful.
• Embedder can do X when a syscall cannot work on that platform (X TBD, should we allow trapping if e.g. sockets aren't available?).
• The module for all syscalls is the same. Say syscall.
• I think we might want to version the module name (i.e. syscall_v0): adding new syscalls doesn't need a new version, but changing any tool-convention ABI behavior would require bumping the version. Unless we think behavior will never change, in which case no versioning.
• The field for each syscall is just the syscall number macro's name (e.g. exit, fork, read, write, open, ...)
• IIRC we've talked about adding a custom clang attribute to denote module / field of an export / import.

One open question I have: say a JS embedding wants to let the user choose how to implement filesystem access (maybe WebSQL versus in-memory are two options). How would be offer a stable ABI, and let users choose which JS glue to use? They can't just change the "filesystem" import if all syscalls are in the "syscall" import. Should we group syscalls by theme, and are all of these orthogonal enough that you wouldn't want to have two in the same group sometimes?

Start by reviewing the existing syscall list in the linked musl wasm prototype and the proposed module, field, and versioning conventions. Work through the open questions about unavailable syscalls, grouping, and selectable JavaScript filesystem glue. Done means the project has an agreed stable syscall ABI and documented decisions for these cases.