-
Notifications
You must be signed in to change notification settings - Fork 240
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
WASI and POSIX? #122
Comments
Use POSIX permissions would make it basically impossible to implement WASI on Windows, as Windows uses ACL's instead of user/group/world read/write/execute/suid. |
I think there are conflicts between POSIX and the design philosophy of WASI. So it seems that full POSIX support is (by design) not goal for WASI. I believe this is also true of cloudabi on which WASI was initially based. I think the idea is the its better to break compatibility for the sake of a better, brighter tomorrow. This does mean I guess that the is room, perhaps not in WASI, to design something more POSIX-ey. |
It would be very valuable to WASI for people to report real-world POSIX programs they wish to run on WASI but which don't work due to WASI's limitations. Obviously there are some big things, like networking, which we do intend to add. I'd be really interested in hearing whether people actually need, for example, full POSIX-style "user/group/other read/write/execute" permissions control in the kinds of programs they want to use wasm for, and how they're being used. Since these have unclear meaning on Windows, and even have some implementation-defined behavior in some of the finer details even on ostensibly POSIX systems, the more we know about how people actually want to use these, as opposed to how they could theoretically use them, the more flexibility we'll have. |
I do hope that WASI can gradually support most of POSIX, including forking, signals, sockets, and shared memory. Maybe even
I don't think that's true: WASI-libc already goes out of its way to emulate the POSIX file API via libpreopen, and it seems like it should be possible to emulate the rest of POSIX on top of whatever OCAP-based APIs WASI adopts in a similar way.
It might not be possible to map file permissions 1:1 between POSIX and Windows, but some useful mapping should be possible.
I don't need file permissions, but it's incredibly valuable for existing POSIX programs to compile and do something sensible. |
I'm curious to hear what people think about how much of POSIX should be possible to implement via WASI.
As a concrete example, I may be wrong but I think you can't implement the commandline tool
ls
in WASI atm, because WASI can't represent the owner/group/world permission levels (there is just "read" permission, but not separately for the owner/group/world, etc.). That is, if one tried to portls
to wasi, I'm not sure how it could print therwx
etc. stuff here;ls
may seem trivial, but this also limits how much Python's system libraries can be ported, for example, as people do use Python to script operations on POSIX permissions. So the systemls, python
, etc. seem to not be replaceable by wasi alternatives atm.Of course file permissions is just an example of something that seems not possible in wasi atm. I'm more curious about the general thinking here. Maybe there could be an optional wasi POSIX module (which would have a
posix_path_open
that parallelspath_open
)? Or maybe 100% POSIX support isn't a use case people here care about?The text was updated successfully, but these errors were encountered: