Why doesn't WASI specify behaviors?

[yagehu]

I understand that WASI is just an interface definition. But does it make sense for WASI to formally specify syscall behaviors as well?

I think specifying behaviors can make it clear how to use these syscalls and what they actually do. For example, in order to use path_open, you would normally have to iterate through the preopened directories with fd_prestat_get. I'm just a newbie and it took me a while (#323) to understand how to use path_open.

It can also allow implementers to build a test suite from the behavior spec. I know there are existing test suites, but without official specification, it's hard to determine what can go into a test suite.

I have a more nuanced example, I was testing fd_prestat_get across different runtimes (Wasmtime, Wasmer, WAVM, SSVM, etc.). I figured out that preopened fds start at 3. I simply wrote a Wasm program that counted the number of preopened directories. You would expect the program to return 0 if you don't tell the runtimes to preopen any directory. But for Wasmer, it actually automatically preopens a virtual directory, meaning the user-specified preopened directories start at 4.

I can see this potentially bring portability issues. Having some sort of behavior specification can prevent that.

[devsnek]

file descriptors are intended to eventually be externrefs, which you would explicitly import (or be given by calls to wasi apis). wasi would specify stdio on top of that. with all that, the magic numbers and iteration goes away.

[sbc100]

file descriptors are intended to eventually be externrefs, which you would explicitly import (or be given by calls to wasi apis). wasi would specify stdio on top of that. with all that, the magic numbers and iteration goes away.

While what you say is true, that doesn't seem like a reason not to work on improving the documentation of the current APIs if they are lacking.

I think we would generally welcome more documentation if folks would be willing to contribute to it.

[yagehu]

I guess I should clarify. I'm not just asking for better documentation. (I would be happy to contribute). I'm asking if WASI should formally specify syscall behaviors.

For example, for path_open, WASI can specify that the first argument must be a preopened directory. If not, it should return error code x.

[tschneidereit]

I agree that WASI needs to specify not just the interface, but also the precise semantics of exposed functionality. Both wrt the behavior to expect when invoking a certain function, and wrt permitted and non-permitted extensions.

We do want to get to a system interface with precisely defined behavior with as much portability as is possible. (I'd like to be able to say "perfect portability", but that's not going to be feasible, given that there are some unresolvable differences between different host environments, e.g. in the area of path handling, case-sensitivity, etc. A spec should ideally also precisely define permissible differences in behavior in these areas.)

[yagehu]

I would love to do some exploratory work in this area. I'm mainly interested in generating WASI test cases that can be executed by various runtimes to determine the level of WASI support they have and how compliant they are to the WASI spec.

[sbc100]

There are efforts underway to build a WASI test suite: #9. Any help there would be much appreciated.