-
Notifications
You must be signed in to change notification settings - Fork 257
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: replaces existing filesystem apis with fs.FS #394
Conversation
e2f28bf
to
840a7fd
Compare
The prior design had a problem, where multiple imports of WASI would end up having different file descriptors for the same file. Moreover, there was no means to close any of these when a module importing WASI was closed. This moves all existing functionality to a new type SystemContext, which is owned by the importing module, similar to how it owns its memory. While this PR doesn't fix some problems such as unclosed files, the code is now organized in a way it can be, and these issues will be resolved by #394. In order to fix scope, `WASISnapshotPreview1WithConfig` had to be removed. Signed-off-by: Adrian Cole <[email protected]>
The prior design had a problem, where multiple imports of WASI would end up having different file descriptors for the same file. Moreover, there was no means to close any of these when a module importing WASI was closed. This moves all existing functionality to a new type SystemContext, which is owned by the importing module, similar to how it owns its memory. While this PR doesn't fix some problems such as unclosed files, the code is now organized in a way it can be, and these issues will be resolved by #394. In order to fix scope, `WASISnapshotPreview1WithConfig` had to be removed. Signed-off-by: Adrian Cole <[email protected]>
44fba44
to
84a369e
Compare
ok this is rebased. next steps before ready for review:
|
Signed-off-by: Adrian Cole <[email protected]>
7281220
to
b15d8ea
Compare
Signed-off-by: Adrian Cole <[email protected]>
Signed-off-by: Adrian Cole <[email protected]>
Signed-off-by: Adrian Cole <[email protected]>
opened #408 to follow-up at some point and add another kind of integration test, now that it is easy to compare against an |
// // Files relative to this source under appA is available under "/" and files relative to "/work/appA" under ".". | ||
// sysConfig := wazero.NewSysConfig().WithFS(rootFS).WithWorkDirFS(os.DirFS("/work/appA")) | ||
// | ||
// Note: os.DirFS documentation includes important notes about isolation, which also applies to fs.Sub. As of Go 1.18, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
took some reading to discover there are no plans for an actual chrooted FS. Until then, folks with high isolation needs will have to write their own fs.FS impl (or find some library that isn't abandoned that tries to do this!)
Signed-off-by: Adrian Cole <[email protected]>
cc @pims this is an API break, but a good one as we've gotten rid of an incompatible FS and formalized the API. Hope this doesn't drift you too much! |
Thanks for the heads-up @codefromthecrypt This looks like a very sensible change and until 1.0 is released, no stress about API breaking changes. |
This changes
SysConfig.WithFS
andSysConfig.WithWorkDirFS
to accept anfs.FS
for the root ("/") and working directory (".") file systems. This allows end users to leverage standard libraries that adhere to this, including OS, HTTP and embedded filesystems.For example, here's how you can allow WebAssembly modules to read
"/work/home/a.txt" as "/a.txt" or "./a.txt":
Note: Further development will happen after this, for example to allow creation of new directories, though priority of that is demand-based. If you need further FS features, you should ask on #390 with your use-case!