Repository navigation
Add serdes API #69
Description
It would be useful if embedders didn't need to worry about serializing and deserializing between WASI data structures and the WASM memory. For example, Node.js currently does this:
uvwasi_fdstat_t stats;
uvwasi_errno_t err = uvwasi_fd_fdstat_get(&wasi->uvw_, fd, &stats);
if (err == UVWASI_ESUCCESS) {
wasi->writeUInt8(memory, stats.fs_filetype, buf);
wasi->writeUInt16(memory, stats.fs_flags, buf + 2);
wasi->writeUInt64(memory, stats.fs_rights_base, buf + 8);
wasi->writeUInt64(memory, stats.fs_rights_inheriting, buf + 16);
}The wasi->write*() calls could be replaced with a uvwasi_serdes_write_fdstat_t(memory, stats, buf).
Another option could be to provide wrappers for each function (uvwasi_serdes_fd_fdstat_get(), etc.). This would take care of bounds checking, reading from memory, executing the WASI API calls, writing back to memory, and forwarding the correct return value. This would be the simplest thing for embedders, but would also require a wrapper function for every WASI API call.
Potentially useful reference: https://github.com/WebAssembly/tool-conventions/blob/master/BasicCABI.md
Any thoughts or opinions from others?
Activity
tniessen commentedon Dec 28, 2019
I think the first option sounds better to me, simply because we won't need an additional layer for every single call. Having
uvwasi_serdes_write_*seems like a good idea!add serdes API
add serdes API
add serdes API
serdes: add support for uvwasi_size_t
fix UVWASIS_SERDES_SIZE macro typos
cjihrig commentedon May 14, 2020
#94 has landed, but I'm leaving this open, as there are still a few things I'd like to address in the new serdes API:
uvwasi_ciovec_tanduvwasi_iovec_t.