Support more socket APIs

[lum1n0us]

Plan to support three more socket APIs

• ~~ int socketpair(int domain, int type, int protocol, int sv[2]);~~
• ssize_t sendmsg(int sockfd, const struct msghdr *msg, int flags);
• ssize_t recvmsg(int sockfd, struct msghdr *msg, int flags);

The socket APIs feature is an experimental feature for now and it is in the dev/socket_api branch.

To support some APIs usually means two things:

• allow the compiler to translate APIs from C/C++ to WASM. It needs WASM implementations of those APIs. Because it happens before compilation(from c/c++ to wasm), the implementation is still in c/c++. wasi-libc is for libc as an example.
• runtime support for APIs. Some functions are so simple that they are able to be fully implemented in WASM. Others may require syscall have to depend on runtime support. An imported WASM function provided by runtime is a bridge.

So, when going to support a API, we shall ask the question: Can the API be implemented with existing APIs? If yes, it means we can give the API a fully WASM implementation. If no, it means we need to add relative capability into the runtime.

Take socketpair() as an example. It is a wrapper of a SOCKETCALL. A syscall means additional runtime support. So its implementation should include:

• an WASM implementation
• an imported WASM function as bridge
• an additional runtime support

Please take a look at

• core/iwasm/libraries/lib-socket/
• samples/socket-api/

Let's talk how to handle marshal between C/C++ and WASM.

First thing is always type. Those WASM implementation have their own types, like __wasi_iovec_t, and they create and initialize values of __wasi_XX types according to original arguments of c/c++ types. For example, the WASM implementation of sendmsg() should translate struct msghdr* msg to __wasi_iovec_t s_data. Then WASM implementations work with __wasi_xx types.

Assume there is a bridge and additional runtime support is envolved. Since runtime will use platform implementation, those __wasi_xx types need to be translate back to original, required c/c++ types.

Second thing is function signatures. For security, we tends not to use the exactally errno between WASM and native. Instead of it, all WASM implementations, includes imported ones, always return error number (__wasi_errno_t) and use an output pointer to carry the original return value.

Good luck and don't hesitate to ask when you have any question.

[lum1n0us]

@BenSunWhiteBoard. Let's do it.

[lum1n0us]

Here is a PR about the issue that includes an example for testing.

[BenSunWhiteBoard]

While I am looking at headers and c source code in directory core/iwasm/libraries/lib-socket/, I can't help but thinking a unrelated question: Do we have a style guide document that I can read or an auto formatter config file? It's just a little different from what I am used to before, I am kinda wondering what the criteria is.

[lum1n0us]

Please use $ clang-format --style=file under the wasm-micron-runtime. It will apply a predefined code style in .clang-format.

[hangedfish]

Is there any plan to support getaddrinfo ?

[lum1n0us]

We might support it in months. A real use case will help to level up the task priority. 😺

[loganek]

@hangedfish getaddrinfo is already supported, see https://github.com/bytecodealliance/wasm-micro-runtime/issues/1336 for details