Add a more general __WASI_FILETYPE_SOCKET #4
Comments
|
[bookkeeping] Added to the Moving wasi-filesystem to Phase 3 project. |
sunfishcode
added a commit
to sunfishcode/wasi-filesystem
that referenced
this issue
Nov 22, 2021
This makes a number of changes, to make use of interface-types features such as expected, variant types, and resources. The change to use resources in particular means that filesystem functions are now methods of the descriptor resource. Since this means renaming everything, take this opportunity to introduce a new naming conventions, with _at being used for functions that take dirfd+path arguments. This also eliminates the rights concept what was present in earlier versions of WASI, has has discussed in WebAssembly#31. This required adding new flags to open_at, so while here, this also adds basic chmod-like support, as discussed in WebAssembly#33. And, this removes support for readdir seeking (seekdir/telldir), as discussed in WebAssembly#7. And it adds a fifo file type and a more general socket type, as discussed in WebAssembly#4.
sunfishcode
added a commit
that referenced
this issue
Dec 15, 2021
This makes a number of changes, to make use of interface-types features such as expected, variant types, and resources. The change to use resources in particular means that filesystem functions are now methods of the descriptor resource. Since this means renaming everything, take this opportunity to introduce a new naming conventions, with _at being used for functions that take dirfd+path arguments. This also eliminates the rights concept what was present in earlier versions of WASI, has has discussed in #31. This required adding new flags to open_at, so while here, this also adds basic chmod-like support, as discussed in #33. And, this removes support for readdir seeking (seekdir/telldir), as discussed in #7. And it adds a fifo file type and a more general socket type, as discussed in #4.
|
The current wasi-filesystem.wit.md now contains a |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Currently, we have
__WASI_FILETYPE_SOCKET_STREAMand__WASI_FILETYPE_SOCKET_DGRAMwhich seems to be a tad bit too specfic for calls such asfd_readdir. That is, when translatinglibc::direntto__wasi_dirent_t, we are required to do custom mapping betweenlibc::dirent::d_typeto__wasi_dirent_t::__wasi_filetype_t, and it becomes convoluted and tricky to properly work out whether we are dealing with a socket stream or datagram. Why is that? Note that when performing anfd_readdircall in WASI, we pass in a descriptor to the directory only; we then receivelibc::direntstructures one by one, and perform translation to__wasi_dirent_t. If the underlying "file" is a socket, we have no way of working out whether it's a stream or datagram without performing another syscall, i.e.,getsockopt(libc::dirent::d_typeonly tells us that we're dealing with some sort of a socket).My proposition here would be to create a more general WASI filetype,
__WASI_FILETYPE_SOCKET, which would act as a catch-all for all socket types, and we would then burden the WASI client to actually perform another syscall to work out what type of socket they are actually dealing with.The text was updated successfully, but these errors were encountered: