Pat Hickey (Apr 28 2020 at 18:16): Pat Hickey (Apr 28 2020 at 18:16):one thing that has come up a few times, including in the last wasi call, is that witx is able to describe the type signatures of modules that a wasi executable may import, but it doesnt describe 1. what the requirements for a module to export are, which is required to specify reactors like proxy-wasm, and 2. which modules in particular are available for import, which will be useful once there are multiple modules being considered
Pat Hickey (Apr 28 2020 at 18:21):so im going to work on an addition to witx that is a (profile $identifier ...) which allows you to specify export functions & memory using the same syntax as modules do, and use (import $modulename) to specify that an import is available
Pat Hickey (Apr 28 2020 at 18:21):it should be pretty straightforward, and i hope that it will be useful. I plan to use it in lucet immediately, but ideally it would be useful by others as well.
Pat Hickey (Apr 28 2020 at 18:21):one idea i had that makes it nontrivial (and wouldnt be part of the initial implementation) is that one desirable profile we might specify is a module which makes multiple wasi snapshots available for import
Pat Hickey (Apr 28 2020 at 18:23):currently, because snapshot 0 and 1 use the same typenames in the global scope, we cant do a (use ...) of both snapshots into the same .witx doc so they can both be included in a profile
Pat Hickey (Apr 28 2020 at 18:24):so this may end up being a forcing function for a suggestion i made a long time ago, which is to introduce scopes to witx somehow, so that theres some hierarchy besides one big top-level scope.
Pat Hickey (Apr 28 2020 at 18:24):i don't have any strong ideas for how to do that, its a bit of a bikeshed
Pat Hickey (Apr 28 2020 at 18:25):i'd welcome feedback and suggestions on how to do that, and anything else related to profiles.
Dan Gohman (Apr 28 2020 at 19:20):one thing that's initially unclear to me is what motivates profile, rather than using export to indicate things you can import from and import to indicate things you're supposed to export
Pat Hickey (Apr 28 2020 at 19:22):profile is really for a world in which you have specified a significant number of modules in witx, and want a way to express what subset of them you actually support
Dan Gohman (Apr 28 2020 at 19:24):ah, makes sense. I think I just misread your comment :-}
Pat Hickey (Apr 28 2020 at 19:24):it also allows us to decouple executables and reactors specifications from import module specifications. if we added export "_start" to the existing wasi snapshot 1 module today, that raises the question of how a reactor uses that
Pat Hickey (Apr 28 2020 at 19:24):and where that export belongs in ephemeral
Dan Gohman (Apr 28 2020 at 19:25):do you mean import there?
Pat Hickey (Apr 28 2020 at 19:25):yes, thats what i meant, sorry
Dan Gohman (Apr 28 2020 at 19:25):We already have an import for "memory", and I agree adding a witx description of _start and now _initialize makes sense
Dan Gohman (Apr 28 2020 at 19:25):cool
Pat Hickey (Apr 28 2020 at 19:27):yes, we should retain the import of memory in every module which requires it (i expect this is all of them until interface types lands)
Pat Hickey (Apr 28 2020 at 19:27):but i guess you could theoretically have some witx-specified module that just sends atoms back and forth and doesnt need to share memory.
Dan Gohman (Apr 28 2020 at 19:36):wasi_ephemeral_sched.witx totally doesn't need memory :clown:
Pat Hickey (Apr 28 2020 at 19:36):hmm yeah maybe only modules that use @witx pointer and const_pointer actually need it
Pat Hickey (Apr 29 2020 at 19:14):ive turned this into a PR
Pat Hickey (Apr 29 2020 at 19:14):https://github.com/WebAssembly/WASI/pull/267
Pat Hickey (Apr 29 2020 at 19:16):initially i allowed (export (memory)) to be specified in a profile, but i realized that this requirement is already covered by the (import (memory)) of the modules available for import. So, I decided that profiles are just a collection of (import $modulename) and (@interface func (export "funcname") <func type information>).
Dan Gohman (Apr 29 2020 at 19:32):awesome, I'll take a look later today
Dan Gohman (Apr 29 2020 at 21:27):initial comments posted!
Last updated: Nov 22 2024 at 16:03 UTC