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
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
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.
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
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
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.
i don't have any strong ideas for how to do that, its a bit of a bikeshed
i'd welcome feedback and suggestions on how to do that, and anything else related to profiles.
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
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
ah, makes sense. I think I just misread your comment :-}
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
and where that export belongs in ephemeral
do you mean import
there?
yes, thats what i meant, sorry
We already have an import
for "memory", and I agree adding a witx description of _start
and now _initialize
makes sense
cool
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)
but i guess you could theoretically have some witx-specified module that just sends atoms back and forth and doesnt need to share memory.
wasi_ephemeral_sched.witx totally doesn't need memory :clown:
hmm yeah maybe only modules that use @witx pointer and const_pointer actually need it
ive turned this into a PR
https://github.com/WebAssembly/WASI/pull/267
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>)
.
awesome, I'll take a look later today
initial comments posted!
Last updated: Dec 23 2024 at 12:05 UTC