wasi design in Walrus

[kulcsaradam]

I have been working on implementing wasi in Walrus and have come up with two design questions. If you would like to check out all of the implementation: https://github.com/kulcsaradam/walrus/tree/wasi_funcs (please note that branch is behind a few commits)

Question 1: How should wasi interact with instances to acces memory and other possible resource? I can think of two possible solutions:

• Expand the ImportedFunction:call function with another pointer to the caller instance ( I have implemented this as of the time of writing for curiosity )
• Search the call stack for the nearest instance and use that

I am open to any other ideas, these are just some options we thought of.

Question 2: I've expanded SpecTestFunctionTypes with types of wasi functions and I am interested if this approach would be sufficient: https://github.com/kulcsaradam/walrus/blob/ecb9fe72d3d55a87d01b9c0c081d556e54d734af/src/runtime/SpecTest.h#L25C3-L25C3 I am open to any ideas if there are concerning this too.

[clover2123]

How should wasi interact with instances to acces memory and other possible resource?

I'm not sure but, are there standard wasi functions that require memory access or other resources of wasm Instance?

[kulcsaradam]

There are some functions that require a uint8 pointer to a buffer or some construct and the memory seemed the easiest and most logical place for these constructs. It is said that the next preview would be moving away from this, but it is not disclosed how.

One of these functions is random_get or functions that require strings could also use the memory through the data segment since Walrus does not implement strings.

[clover2123]

It seems that this issue is quite difficult to deal with right now. I also found that the reference WASM engine (wabt) is not yet supporting these features as well. IMO it may be better to postpone and discuss it later after other WASI features are fully supported. By then, we can get some hint from other WASM engines or WASI standards may change its specifications. AFAIK most of WASI functions can be implemented independently from internal resources.

[kulcsaradam]

As I looked into different engines ( mainly wasmer ) those use the memory of the running instance for these operations too. Not implementing these features could limit the ability of usefulnes of Walrus WASI quite considerably, but I understand the difficulty too. Also as I were experimenting with it, using the data pointer in call function to pass the current instance seemed manageable.

Though if you'd like I can close this issue for now and return to it when WASI changes or when we have a more solid design idea around this problem.

[zherczeg]

I think we should figure out something for this issue. Buffers are needed for transmitting strings, file data, socket communication, etc. We could:

• Provide the memory object as an argument for calls. This is ignored by byte-code functions, so it is an unnecessary operation for them.
• Allow getting the memory object of the last instance for C callbacks. This method needs checking the call stack (might be hard for JIT).
• Create a shared memory block for communicating with Wasi, and map it as a secondary memory object. The memory.copy can be used to copy data here. Hard to use it from a C code compiled to WebAssembly.
• Convert offsets to pointers. It is hard to know that the i32 data is a pointer, so all of them needs to be converted.
• Do you have any other idea?

[kulcsaradam]

Resolved by #160 .