Adding document for comment

[woodsmc]

Added the document in its current state for comment as an open PR.

[abrown]

Abandoning these early adopters without a viable migration path...

This is not a fair judgment of how toolchains like wasi-sdk and wasi-libc have approached the requests for longer support of p1 — I would say this language is a mis-characterization and should be fixed. I have had many conversations with @woodsmc, @loganek, etc. in which they expressed a desire for long-term support for p1 in those toolchains. And, in fact, here's one of my efforts to support that desire from exactly one year ago: WebAssembly/wasi-libc#476.

But note the lack of feedback from the "keep p1 alive" parties in that PR: I believe that it is the responsibility of those who want to maintain p1 stability to be invested in that work, not leave it to others. Those who are moving the specification forward (p2, p3, etc.) should not be forced to have the same stability motivation as the "keep p1 alive" parties. And that is an open invitation for the "keep p1 alive" parties to increase their support for the parts they care about; I feel both goals, progress and stability, are still clearly possible at this point.

[rajsite]

Maybe it's an oversimplification / mischaracterization but I believe the largest concerns with preserving p1 interfaces is more about preserving core wasm module format and interfaces. I'm optimistic that WebAssembly/component-model#378 will provide the alternative that the "keep p1 alive" parties would want without the current limitations of what is in the scope of p1 / extending the interfaces in p1.

[abrown]

@rajsite, yeah, I agree with your "largest concerns" assessment. And I guess that strengthens my point: it is not as if toolchain maintainers have "abandoned" p1, but rather that the companies represented by this document should invest in making the issue you link to (and/or my draft PR) a reality.

[woodsmc]

Hey @abrown, thanks for considered thoughtful feedback, it really is much appreciated. In large what I hear you saying actually aligns with the document. You are highlighting the need for those organizations who require the 0.1 toolchain to get involved with it, as the those taking the standard forward don’t see a need to do so.

There is no judgement in the document. But the document does need to very clearly and very transparently describe the state of current support for the WASI 0.1 toolchain, along with the wider implications of this.

There are organizations I have met who believe that WASI 0.1 is going to have indefinite support. They believe that this support will be provided for by those moving the standard forward. This is not my understanding. Reading your comment you seem to suggest the same thing. The mistaken believe that there will be indefinite support has resulted in a lack of attention on WASI 0.1 stability – something the document is trying to address.

Are there any published plans for WASI 0.1 support, that the document authors may have missed? – If so then yes then we should accurately reflect these in the document.

My honest, personal understanding is that this does not exist. My understanding is driven by my personal conversations with you, other members of the BCA TSC and folks in Fastly and Cosmonic. When I enquired about longer term support the response I received was the same from every party, that WASI 0.1 was a preview and should not be used. As I explained on the E-SIG call, and included in the overview of the document, that boat has sailed. We (those people using WASI 0.1) need to provide this missing longer term support.

As we move forward to provide this support and start defining the concrete next steps there may be initiatives that we’ve not been involved in which we should. The PR you linked to is a great example of that, and I’m grateful you pointed that out.

Regarding the next steps, I am much more interested in yours and others’ opinions on how the renewed investment in WASI 0.1 can be managed alongside the evolving 0.2+ releases. The document authors spent a considerable amount of time trying to work out a compromise that could work for all.

I can see the WASI 0.1 / Embedded folks wanting to move forward with some new additions to WASI 0.1 to provide missing system level functionality. I can envision this happening within the next month or so.

[woodsmc]

@rajsite, yeah, I agree with your "largest concerns" assessment. And I guess that strengthens my point: it is not as if toolchain maintainers have "abandoned" p1, but rather that the companies represented by this document should invest in making the issue you link to (and/or my draft PR) a reality.

This appears to be a call to action. I love this, and I really appreciate you calling out the need for investment. It is something we should consider in the E-SIG as we define the concrete next steps.

[ttrenner]

From what I've seen it'd be correct to state that there are existing approaches to support migration in terms of the generation of wasm modules (by wasi-sdk) (based on your sketched approach) and proposals that could help to make p2-modules workable on p1-runtimes (see Marcin's proposal).

Other than that, the document tries to state that there are gaps in current p2 tooling that reflect p1 functionalities and non-functional requirements of the embedded domain. That does not mean, that there are no ideas of how to do that based on p2. It just means, that it does not exist yet. Plus, there are concerns that - in case that there will be no means/support for low-level api support - P2 might not do the trick for the needs of the embedded domain. This concern might be wrong, but it is reality, that p1-based products are already running on tons of "embedded" devices. So, p1 is "proven in use" and hence the risk of extending and improving p1 seems to be lower than hoping that P2+ will work for the embedded domain in future.
The concerns about P2+ could somehow be tackled if there is an agreement to place quality gates in the phases. Note, that this is also brought up in the document. I have not seen any comment on that, which makes me feel like that there is little to none support for that. Again, bear with me if I am wrong with that - maybe there was no opportunity to dig into this.

The document also tries to sketch an solution to let both concepts (P1-like and P2+) work: a layered approach. The bottom layer is just about supporting low-level APIs, while the top layer does all the nice things to get interlanguage interoperability (component model) - by the way: having a well-defined way for FFI declaration is wanted by the embedded domain but not for the price of performance, when performance is more important and Posix, using C ABI etc., does the trick (also accepting the trade-off of being forced to accept another way for FFI declaration or the trade-off of not having the possibility to mix languages).
Now, there are comments that the layering approach might not be necessary, because it might be doable with P2+ approaches. This seems to be a bet in the future, at least as long as there are no working examples showcasing this broadly. I admit that there are examples when looking at shared memory. Stream of P2+ seems to serve well for a couple of use cases. But there are use cases where stream does not seem to be the best solution (e.g. in case random access is needed and well-known MMU features (using mmap) are enough for a specific use case). Plus, there are different approaches out there, e.g. WAMR's shared heap (which also does not fit for all the uses cases that need "shared memory": e.g. if sharing is needed across different processes (albeit with all the cons that come with it!)).

There is legacy software, that is based on Posix. There is legacy software, that should be ported easily to the wasm world, i.e. clone the repo and issue clang/cmake and generate a wasm module. There are missing gaps like signaling (which has been discussed here back in the days). In the linked issue it is highlighted, that signal handling is not an easy task and maybe not everything is needed (and not all of it might be sensible in the "Wasm realm"). Also, maybe, not everything of Posix is needed. But we do not know yet. But we know that there are examples that need to set thread-attributes or socket options (e.g. unblocking source). Such software needs more "posix like" support and it feels to become overcomplicated (incl. performane loss) to map (and re-do?) it to p2+ approaches if it is not needed for a given use case.

Long story short: Anticipating all the different use cases does not seem to be realistic and hence we are advocating for a more flexible approach of interacting with the "underlying system" - I think that the layered approach is worth to be discussed. I'd be irritated if this is not even considered worth to talking about.

[edit] changed some wording and typos - sorry for the inconvenience.

[woodsmc]

In large what I hear you saying actually aligns with the document [...] But the document does need to very clearly and very transparently describe the state of current support for the WASI 0.1 toolchain, along with the wider implications of this.

I do understand many of the underlying concerns but what I'm pointing out is that what the document is describing, whether clearly or transparently, is actually incorrect: IMHO, p1 users have not been abandoned by toolchains and there is a viable migration path (see the links above).

@abrown - There has been a tremendous amount of engineering and effort expended to keep the WASI 0.1 tool chain functioning as it is today. You are right we should call this out in the document. It is something I know all users of WASI are very grateful for.

The document is doing a little bit of a hamfisted job of it, but it attempts to point out that there is such a resounding lack of commitment from anyone, either the users of 0.1 or the contributors to moving the specification forward to maintain that support. We know that there are commitments to continue work on WASI 1.0+, but nothing exists for 0.1, this lack of support (it doesn't appear deliberate, more like it's fallen between the gaps) is effectively the same as abandoning the 0.1 users. This is particularly true when you combine it with the lack of WASI 0.1 runtimes to execute code targeted at WASI 0.2,0.31.0RC and beyond. The result is a tool chain that's no longer supported and a runtime that can't execute the latest binaries...

In drawing attention to this, the intent in the document, is to demonstrate the need to step up and contribute.

I'd appreciate some help with the wordsmithing to get this all in the document.

[squillace]

Yes. Two concepts:

1. is there a technical path toward useful support until components deliver the same feature set on target devices?
2. who will implement and maintain that technical path?

Those concepts are both required in the new document, methinks.

[abrown]

In response to @ttrenner, I would like to point out that I am quite sympathetic to the desire to avoid unnecessary overhead when accessing HW; I'm sure I've annoyed some with my intent focus on this in the past! So I am all in favor in discussing ways to make things more performant and this document is aiming towards that direction — all good! What you may be missing is that I'm objecting to is the blame-based language used in the document, which @woodsmc picks up on in his comment. It feels a bit unfair to those of us who do work on these toolchains and have tried, as time permits, to help. My opinion here is that current p1 support and the migration to p2 has not been "abandoned" as much as "not worked on," hence my call to get more implementations involved; like @squillace points out, "who will implement and maintain?" And @woodsmc, I'm not sure I agree with your latest conclusion that "the result is a tool chain that's no longer supported," — do you mean this is the state you see today or a state that could be some future? My take is wasip1 is still being used effectively out in the wild for several languages...

I don't want to put words into your mouth, but to wordsmith this, could we:

• retain the concerns about toolchain gaps that may appear in the future; sure, more must be done if long-term stability is a goal
• link to some of the examples I mention as plans that would improve the situation but require implementation
• make a call to implement in that direction (it doesn't have to be those specific ideas); I feel the real focus of these paragraphs should be just that, motivating the implementation and maintenance of high-quality, stable previews
• avoid blaming the ecosystem that the eSIG is benefitting from; perhaps some recognition for the engineers who have brought the toolchains to this point (and I don't mean me, there are many who have contributed much more here!)

@woodsmc, what do you think of that?

[woodsmc]

@abrown Thank you! - and hey, don't worry about putting words in my mouth at all - It was a honest call for help, and I really appreciate your input! - so, yeah, big thank you.

I agree. Let's go through the document and make sure it doesn't blame, that's not the intention. The intention is to detail where we are the moment in a kinda open and frank way. I've unfortunately not been able to hit my own milestone, and I apologize for that.

What I can see, (if I attempt to TLDR this in a comment), is that there has been an initial investment in WASI which has been tremendously successful. The new investment (P2+) is heading in a direction which will not serve a not-insubstantial subset of the users of the original WASI work, mainly members of the E-SIG, and there is now a need to address this. The direction of the new investment also leaves those who invested in 0.1 runtimes without a migration path to execute the output of future WASI SDKs.

There is no blame here. It "just is what it is", or "we are where we are". But in addressing it this way, and detailing what would happen if it is not addressed, the document attempts to get the reader focused on the need to contribute.

I also think we need to highlight where some of the investment is going to need to come from to address this. The document attempts to point out, that the need and desire of those organizations who are driving WASI at the moment, to maintain the WASI 0.1 SDK declines as WASI 1.0 approaches. - this isn't wrong... it makes sense for those organizations... no harm, no fowl, it just is what it is.

Therefore... those folks using the WASI 0.1 SDK need to start getting involved and helping to contribute.

This is mainly covered in the first half of the document. The second half covers how this might be done.

I'd like to update the document to ensure that the tone is right, but to also make sure that the need for additional contributions is still there. I will go through this on Monday and update it.

I also agree with Oscar's feedback, that we can do two derivative documents, one which details the need to get involved and the WASI 0.1 SDK need for the E-SIG, and the second for talking more about how we'd do that.

I feel like this document has really done it's job of provoking the conversation and as an internal E-SIG discussion piece it's been pretty good in doing that. Now's the time to move on to more concrete steps, how do we support the 0,1 SDK? and if we add to it, how do we do that?

[abrown]

@woodsmc, thanks for moving this to a separate PR — it's a lot easier to review. Have you already dealt with the issues brought up in #10 or were you planning to get to that at some point? (I just didn't want that valuable feedback lost in the move!).

[woodsmc]

Thanks for reminding me!- That is very much appreciated. For completeness I've copied @lukewagner's original issue text from here and I've inlined my responses from that thread. The two edits suggested in my responses have been applied ( I know these got a little lost in the transfer to the PR, I appreciate everyone's patience with this). To help the reader, my original responses from the original issue are prefaced with "As noted:".

Unfortunately #9 was not kept open to allow feedback; perhaps we could do that in the future since it makes it easier to have threaded discussions.

As noted: Good call. Wasn't intentional and good feedback.

In any case, there are some pretty significant inaccuracies in the Introduction, Problem Definition and Status Quo sections, which I'll quote and describe:

An initial release candidate for WASI 1.0 is expected to be released by the end of the year. However, based on current implementations and the publicly shared roadmap, WASI 1.0 will be largely unsuitable for embedded applications.

I don't know where this comes from, but it's quite untrue. The timeline presented at the last two CG meetings indicates a 1.0 "release candidate" no earlier than mid-2026. And then further work is required to (1) split off a separate W3C Working Group for WASI, (2) advance stages from "release candidate" to actual standard 1.0.

As noted: Yup, let's update the document to reflect that. This now reads:

As of early 2025, the WASI 0.2 release is available, with 0.3 expected in the coming months. An initial release candidate for WASI 1.0 is expected to be released by no later than mid-2026, at which point there is a desire to seperate the standardization process by the creation of a new W3C charter - [link with details]([Wasm CG Feburary 2025 - Google Slides](https://docs.google.com/presentation/d/1z0WXS5BLFtbVynM9xAyilecYskN1IKe9Dad1nDEmgU8/edit#slide=id.g33067d21cc1_0_321)).

Thus, it's far too early to speculate on whether or not WASI 1.0 will be suitable for embedded applications and so I think this paragraph should simply be removed.

A significant challenge is the lack of a viable migration path for existing WASI Preview 1 runtimes. [...]

There are several migration paths being discussed at this moment with folks in this SIG. One of the most promising, whose viability is already demonstrated by jco, involves preprocessing component binaries into core modules that can be run with modest additional effort by existing core wasm runtimes. Extending this approach to more core runtimes like WAMR seems quite viable, and so the quoted sentence and much of the following paragraph seems incorrect. I think it would be more appropriate to explain the current challenge and say that solutions exist that would require far less engineering effort than implementing the Component Model from scratch.

As noted: To be 100% transparent with everyone we should state the difference between feasible, viable and concrete reality. Jco show's a feasible way of addressing this. It may not be viable due to binary image size, implications on potential changes to runtimes (which won't work for ROM based RTs which cannot be updated), performance and memory footprint. From a concrete reality perspective, there isn't a single partner who has committed to build the necessary Jco like infrastructure for the embedded ecosystem.

We should be really very clear with everyone about this. In this regard, there is no solution yet. It is important that we call out this gap. When WASI RC 1.0 is released in 2026 what support will P1 runtimes have? Pretty much none - This is critical to know for everyone, particularly in the embedded folks, as it has a direct impact on business continuity.

Another critical gap is the absence of low-level, system-oriented APIs that are both efficient and predictable. [...]

There are indeed low-level system-oriented APIs that are actively being implemented and proposed in WASI and the Component Model. While it's true that there is more work to be done to reach the optimal goal state, there's more work to extend WASI Preview 1 as well, and the primary challenge here isn't specific to the Component Model at all; as #7 illustrates, the key tensions are inherent to WebAssembly and concern designing efficient, portable, secure APIs that run across the embedded target matrix this SIG has produced. Instead, I think we should list the concrete use cases which are currently sub-optimal, under which we can list the solutions being proposed for implementation.

**As noted: ** It's really important to be clear with the reader - these interfaces are currently not present. In this regard the document paints an accurate picture, they don't exist.

I do understand that there are steps to address this and a desire to do so, which is awesome. While there is a lot of good will to try to overcome these issues, I don't recall seeing any contributor promise to provide this, nor do we have a standards process that would mandate it.

So we have to be transparent - right now it doesn't exist. It may not exist in WASI 1.0 RC in 2026.

Finally, there is no straightforward way for core WebAssembly modules to interact with Component Model-based binaries. [...]

There are a number of ways this can work. One browser-oriented solution is arrived at at the end of component-model/#275 which could work analogously outside-the-browser. Stating "there is no straightforward way" is thus not true; a more accurate statement would be that it is not implemented yet.

As noted: Good point. Let's update that to "no currently available way" (done). This now reads:

Finally, there is no currently available way for core WebAssembly modules to interact with Component Model-based binaries.

As a higher-level abstraction, the Component Model introduces inefficiencies and limitations that make it unsuitable for many low-level use cases.

I don't think this is true as a general statement. The Component Model already avoids many forms of overhead through its low-level Canonical ABI, and most of the remaining known problems are in the process of being fixed. Instead, I think we should list the cases where the Component Model's Canonical ABI is currently sub-optimial, and we can then list the particular changes/additions being discussed that would fix these. As is, the document ignores all the hard work and discussion across this SIG that has been done specifically to address these concerns, such as CM/#383, CM/#175 and, most recently, discussion around whether we could standardize WAMR's shared heaps feature. Leaving out these developments significantly skews the overall picture.

Problem Definition
[...]
Key challenges include:

Items 2 and 3 should be reworded to reflect the comments above.

WASI 0.2 (previously known as “Preview 2”) – Announced three years ago and officially released one year ago

WASI 0.2 was released one year ago; I don't know where "announced three years ago" comes from. The implication seems to be that 0.2 was mostly-done for three years, which is quite untrue; 0.2 only finished implementation a few months before it was released.

As noted: There is no implication intended. Only the desire to state the date of the announcement, as this clearly impacts adoption of Wasm / WASI, the traditional case study for this is The Osborn Effect.

100% let's correct the date. If you've a more accurate date for the announcement, we can change this.

WASI 0.3 – Currently in development, this version is expected to be released within the next six months, further iterating on the Component Model-based approach. It introduces enhancements to asynchronous operations, including the addition of future and stream types

As relevant to this document, we should extend the end of the second sentence with "and a low-level memory-sharing ABI for efficient bulk transfer of data into and out of WebAssembly linear memory".

As noted: Could you be a bit more specific? - Are you talking about caller supplied buffers? Or streams (since the sentence states streams already?) - Regarding efficiency, do you have a data point you'd like to share? - I know a lot of the document discusses efficiency, so a data point here would be wonderful, particularly one that contrasts the same operation with native, 0.1, and the 0.3 version. It would be epic!

With WASI 1.0 expected to finalize this transition, existing WASI Preview 1-based runtimes and applications face an uncertain path forward. The lack of clear migration options risks fragmenting the ecosystem and leaving many early adopters behind.

This should be updated according to the above comment to mention the options available to us to allow existing core runtimes to support WASI and the Component Model with minimal additional effort.

[squillace]

re:

So we have to be transparent - right now it doesn't exist. It may not exist in WASI 1.0 RC in 2026.

I continue to read "may not exist in wasi 1.0" or variations and I want to make it clear that this is what the spec work is for, this is why we do this together. Fusion power also may not exist in wasi 1.0, but if we want it to, we make that happen by participating in the work to drive it. That work starts with targets/user stories formally put down.

I absolutely support and agree that they don't currently exist. That's what this process is trying to create. Per @lukewagner: Instead, I think we should list the concrete use cases which are currently sub-optimal, under which we can list the solutions being proposed for implementation. Without concrete use cases listed, we can't design. Without design, no one can implement (and of course who remains an open question that we know about).

re:

I know a lot of the document discusses efficiency, so a data point here would be wonderful, particularly one that contrasts the same operation with native, 0.1, and the 0.3 version. It would be epic!

This is something the SIG can provide by doing the work to test it. Let's make that operational. The SIG should propose to create efficiency targets using the same hardware targets it's already listed, and then propose benchmarking p1 and p3 to see whether they meet the targets and if not by how much. That would be a strong proposal and also actionable.
A document that continues to ask for others to prove something isn't constructive.

[squillace]

I note of course that those two items do not address the transition from p1 to cm; that's a different bit of work. High order bit is to make cm hit all hardware and efficiency requirements, as if it does not no one will migrate as it provides no business value for the scenarios. Right?

[woodsmc]

Let’s go back to the context of the document for a moment. We have a situation where many members of the E-SIG have products based on WASI 0.1 or are planning to launch products based on this. WASI 0.1 largely meets their requirements and is via wide market adoption both by runtimes and deployed devices deemed production ready. In contrast WASI 0.2+ doesn’t meet these requirements yet, has one implementation and who’s own creators note it is not production ready.

I can see the comments calling for a contribution to the WASI 0.2+ to make that a better fit for the embedded community. I would, like you very much welcome it. However, the commercial reality I, and many I’ve spoken to the in the E-SIG face make this hard to justify. If we only contributed to WASI 1.0 we would be waiting 2-3 years to have something ready to ship, and stagnation for products already in the field. We can't do this.

There are two key things WASI 0.1 users require, near term additions to WASI 0.1 and long-term support for the 0.1 toolchain. (If I didn’t do a good enough job in the overview, let me know – I’ll happily correct it).

The document, rather diplomatically I think, manages to point out that we in the WASI community have managed to simultaneously employ both the Osborn and the Ratner effect, by messaging that the latest standard isn’t as good as the next (Osborn) and that the only version with wide adoption isn’t good (Ratner) when it actually is – the combined impact is that we are driving people away from both WASI and Wasm. Which is hurting us all.

The document suggests that by providing stability around 0.1, we will arrest the Ratner effect and help with adoption. Helping us all.

So we have to be transparent - right now it doesn't exist. It may not exist in WASI 1.0 RC in 2026.

I continue to read "may not exist in wasi 1.0" or variations and I want to make it clear that this is what the spec work is for, this is why we do this together. Fusion power also may not exist in wasi 1.0, but if we want it to, we make that happen by participating in the work to drive it. That work starts with targets/user stories formally put down.
I absolutely support and agree that they don't currently exist. That's what this process is trying to create. Per @lukewagner: Instead, I think we should list the concrete use cases which are currently sub-optimal, under which we can list the solutions being proposed for implementation. Without concrete use cases listed, we can't design. Without design, no one can implement (and of course who remains an open question that we know about).
Right. The document attempts to suggest that we could work on 0.1 and share learnings and approaches with folks working on 0.2+. But we have to do this within the resources available, it’s not for a want of desire, it’s for a near term goal and commercial limitation.

re:

I know a lot of the document discusses efficiency, so a data point here would be wonderful, particularly one that contrasts the same operation with native, 0.1, and the 0.3 version. It would be epic!

This is something the SIG can provide by doing the work to test it. Let's make that operational. The SIG should propose to create efficiency targets using the same hardware targets it's already listed, and then propose benchmarking p1 and p3 to see whether they meet the targets and if not by how much. That would be a strong proposal and also actionable.
A document that continues to ask for others to prove something isn't constructive.

The document is actually full of constructive ideas on how we can address the near-term commercial requirements without hindering the WASI 0.2+ development. We want WASI to succeed.

My remark was a request for clarification from Luke, who has been working hard on bulk data transfer. Luke said it was efficient, so I was asking for the data on that so it could be accurately represented in the document. It’s what we do as engineers and scientists, we look for the data. After all, Einstein not only told us that E=mc2, but he also went on to prove it, it would have made for a very short paper, and lack of publication, dissemination and acceptance if he hadn’t.

[lukewagner]

@ttrenner

Your assumption is, that everyone in the world rather would like/can afford to have a mechanically-derived ABI instead of using a custom ABI (usually C ABI). [...] But I think, that this is not beneficial for every use case out there.

You're right that there are special cases that require special support, and in such cases we have several options with the mechanized approach: add new built-ins (with custom core signatures), add new WIT-level types that have more-advanced ABIs, add more-advanced ABI options to change the ABI of existing types, or some combination of these. This is already what we're doing with 0.3.0, as well as the follow-on additions that I've been mentioning already in this PR. If we expected 100s of such additions, this approach of course is too onerous. But pragmatically, I don't think there are. Again, I think enumerating concrete use cases in WSI in a list and talking through each one in detail could help us feel more at ease.

[woodsmc]

I think what we are talking about here is the disproportionately larger impact that additional instructions have on lower powered (embedded) processors compared to server grade hardware, particularly in relation to control loops. I don't think benchmarks would necessarily help when conveying the differing perspectives. Perhaps if we thought about this from the number of CPU instructions executed and latency.

If we consider a function which needs to pass a buffer of n bytes, if we pass this via a pointer, it is of course O(1). If we have to copy this data it would be O(n).

On cyber physical systems we are largely I/O bound, reading external real world state and instructing external real world devices to move. Given the processors speed and the reaction time we must have, there is a budget of instructions and clock cycles we can spend consuming, processing and responding to the outside world.

Available Instructions for Logic = (required response time * instructions per second) - (instructions for input data + instructions for response data)

If we take one of the processors on the E-SIG list, let's say the ESP32-C6, Risc-V processor. It has a clock speed of 160Mhz, so roughly 160M instructions per second. Let's assume we need to reply to an input signal in say 20 microseconds. That would be ( 0.00002 * 160M) = 3,200 instructions. (note: Microseconds, for some use cases can be really big - occasionally we deal with single digit nanoseconds).

Now we must remove from that 3,200 the number of instructions used to read the state of the outside world and output our response. If the cost of data input / output is O(1) then we can take a fixed cost away 3,200 - 2O(1). If the cost of data input / output is O(n) then of course we have 3,200 - 2O(n).

I know the cost of using a CM can be mitigated by putting everything into the component, but if a component barrier exists between the code and the host, then I still face this input / output cost.

Now, outside of the control loop, where we may interact with an enterprise application, then yes, that's where the component model will offer huge advantages. But for this tight timing it's impact can be pretty large.

As an aside - It also means that the async like interfaces being proposed are not usable for us. Since we'd need tighter control of the scheduling and timing to meet the latency and response times we must deal with.

[Edit: Typo]

[woodsmc]

@ttrenner

Your assumption is, that everyone in the world rather would like/can afford to have a mechanically-derived ABI instead of using a custom ABI (usually C ABI). [...] But I think, that this is not beneficial for every use case out there.

You're right that there are special cases that require special support, and in such cases we have several options with the mechanized approach: add new built-ins (with custom core signatures), add new WIT-level types that have more-advanced ABIs, add more-advanced ABI options to change the ABI of existing types, or some combination of these. This is already what we're doing with 0.3.0, as well as the follow-on additions that I've been mentioning already in this PR. If we expected 100s of such additions, this approach of course is too onerous. But pragmatically, I don't think there are. Again, I think enumerating concrete use cases in WSI in a list and talking through each one in detail could help us feel more at ease.

This looks like a great idea for a more detailed discussion around a second more focused document - #20 ?

I'd love to get this current document merged, with some edits around language. It has done it's job in provoking the discussion. If we move on to some extra detail and some more concrete actions that would be awesome.

I think for the next SG meeting we should present on the use case and need for P1 support... essentially setting out the requirements for the discussion, and outlining what the goals of this discussion would be.

[fitzgen]

@ttrenner

We have other benchmarks, that where already published by @woodsmc (I guess back in 2022), that showed, that execution with wamr was faster than with wasmtime (with permuted, but comparable optimization settings and compilers (llvm/cranelift)).

We are not discussing engines, we are discussing APIs to external resources and the potential overheads of language features, so that benchmark comparing WAMR and Wasmtime isn't relevant at all.

What would be useful would be taking the same program(s) -- ideally one(s) the SIG cares about or believes to be realistic/representative -- and compiling it(them) to both wasm32-wasip1 and wasm32-wasip{2,3} and running both versions in the same engine so that the only variable changing is which version of the external APIs are being used. That would give us information about what kind of overheads, if any, the newer versions of the APIs impose for these programs that we care about.

And we have some internal benchmarks, running on a Cortex-M (~120MHz, FreeRTOS), that does a fourier-transformation

Based on your description, this sounds like a purely compute workload that minimally interacts with the filesystem or other external resources, and therefore not useful for evaluating APIs to external resources. It seems like it would be fine for comparing Wasm execution throughput between engines or to native (modulo the usual qualifications that micro benchmarks are not representative) but it is not useful for this discussion about external APIs.

[ttrenner]

@fitzgen Yes, you're right. My above statements where just about to highlight which "dimensions regarding performance" we are looking at.

I'll take your suggestion to discuss that in the SIG embedded.

[ospencer]

@woodsmc One thing that would help tremendously—could you separate out all things that are changes to implementations versus things that are changes to specifications? As a part of the BA and the E-SIG we're largely focused on things we can implement based on existing specifications. It's fine to have a list of things that would be nice to change in the WASI spec, but those discussions largely need to happen as a part of the Wasm Community Group—that should be a separate document that's presented to the CG. As a bonus, this will give this document a lot more focus, and we can work towards solutions with existing specifications.

[srberard]

While this document is not perfect, I'd like to see us merge this and start work on refining/updating it as a group. The fact of the matter is that today, we do not have a good solution for supporting existing code. As @ttrenner points out, it should be easy to take existing code and retarget it to WASI. WASI P1 is a big step in that direction but, as pointed out here, there are gaps. I'd like to see us pragmatically address these while, at the same time, not impede existing efforts around the Component Model.

I'll start by saying that I'm a fan of the WASI Component Model. I believe it offers a lot of advantages for application development as it introduces a modular approach bringing benefits like composability and language interoperability. However, systems and embedded programming generally have different priorities. These workloads emphasize efficiency, direct host interaction, and minimal abstraction, as they often run in resource-constrained environments where performance and simplicity are critical. While the Component Model provides useful capabilities for many use cases, its additional complexity is not necessary for low-level systems and embedded programming, where a direct and highly predictable execution model is required.

A concern, which has been expressed several times, is the overhead the Component Model introduces. While there has been several proposals and discussions about potential optimizations, concrete solutions have yet to fully emerge. I appreciate the willingness to address these and engage on such topics. However, in resource-constrained environments, added layers can negatively impact performance and increase complexity without clear benefits. In contrast, a direct syscall interface—like the one WASI P1 provides—is a well-established, efficient model that aligns with the needs of low-level software. I'm not saying that the CM won't get there, rather that it's not clear today and my bias is towards a simpler approach for these types of applications.

I agree with the proposed layered approach to WASI. This is a common design pattern for platforms such as WASI. Rather than suggesting a fork, I see this as an opportunity to have a structured approach to WASI, ensuring that development progresses concurrently while saying aligned. For example, I see opportunities for low-level APIs to support and provide the foundation for the higher-level CM model interfaces.

[woodsmc]

@woodsmc One thing that would help tremendously—could you separate out all things that are changes to implementations versus things that are changes to specifications? As a part of the BA and the E-SIG we're largely focused on things we can implement based on existing specifications. It's fine to have a list of things that would be nice to change in the WASI spec, but those discussions largely need to happen as a part of the Wasm Community Group—that should be a separate document that's presented to the CG. As a bonus, this will give this document a lot more focus, and we can work towards solutions with existing specifications.

Hi @ospencer, thanks for the feedback and suggestion. I think others have noted this in comments and in the document. The specification constrains the implementation space, this then dictates the performance of any implementation. You are correct that the specification changes should be discussed at a standards group. I think the right venue for most of this is probably the WASI SG, not the Wasm CG.

Interestingly, the document not only includes features / specifications, but also touches on changes to the standardization process itself.

Looking back at our charter, this document mainly address area 3 of the charter, and in part also areas 2 and 4. The logical next step, once this working document is merged, is to work on two presentations / technical notes to the SG as derivates of this document. These would be:

• Area 3 : Support for maintaining the existing tooling for WASI Preview 1
  Here we can provide the general use case, along with the set of features we would need to see added to the WASI 0.1 release.
• Area 4 : Forward Compatibility / Roadmap for future Convergence
  Here we can provide the proposed standards process mechanism for contributing to 0.1 while not slowing work on 0.2+. We can propose the phase gate quality changes (NFR checks) to the phased approval process which would help the CM naturally move to a state which is more amenable to use in the embedded world.

I expect these will be more concise. How about we add two new issues to track these two technical notes?

Edit: Issues here:

• Technical Note E-SIG -> SG : Area 3 Support for maintaining the existing tooling for WASI Preview 1 #19
• Technical Note: Area 4 : Forward Compatibility / Roadmap for future Convergence #20

[woodsmc]

Hey Folks... since this is an E-SIG that will not be presented to the SG in it's current form, following @ospeencer's suggestion, I'd like to set myself, and the document authors a challenge. Let's look to gather all feedback by Monday March 3rd close of business, US Pacific time. Then look to make sure that the document authors have addressed all the feedback by, say Thursday March 6th close of business pacific time. With a view to getting the document merged by end of the week next week.

Bit of a forcing function, but just so we don't spend too long on it, and move on to some of the constructive and exciting work we have in front of us.

Thoughts? Too short?

[lukewagner]

I'm afraid I don't see how what is described here can be called "layering" when it comes to standards. In particular, the "WSI" interfaces would have custom-designed ABIs that are unrelated to WIT and the Canonical ABI. Thus, if the "WAI" layer wanted to use the "WSI" layer, someone would have to hand-write an adapter for each WSI function to the Canonical ABI (in the same way that folks had to hand-write the Preview1-to-2 adapter -- a tricky bit of work). Thus, this is not a layering of standards. By the same token, one can implement WASI in terms of Web APIs, but the WASI standard is not "layered" on Web standards.

If there is no "layering" relationship, I don't think it makes sense to attempt to introduce "WSI" as a separate standard as part of WASI. This will make an already rather-complex space of standards even harder to understand since there is no "factoring out" of common concepts; it's just more moving pieces.

Now, I do appreciate that, until we implement improvements to the Canonical ABI (caller-supplied buffers, removing cabi_realloc, etc), embedded folks wanting to ship something in the short term (which, iiuc, is another implicit goal here) may not want to use the Canonical ABI -- there are valid reasons to want to hand-craft new ABIs in the interim. But we also don't need to standardize these interim things for them to solve our short-term needs (indeed, attempting to actually standardize them will just work against the goals of being short term).

Thus, I'd propose that the E-SIG reframe "WSI" to be a WAMR project that extends Preview 1 with additional functionality but also with an eye toward convergence with the Component Model along with the explicit understanding that, to converge, folks in the E-SIG will need to hand-write an adapter between WSI and the Canonical ABI (analogous to the preview1-to-2 adapter). As long as the E-SIG provides the engineering resources, I can see this being a valuable addition and I'd be happy to continue working with folks in the E-SIG to plan the convergence, enumerate the remaining gaps and close them.

[srberard]

The concept of layering here is about separating lower-level and higher-level abstractions in a way that aligns with our standards approach. Rather than conflicting with it, this proposal fits within the existing process and maintains alignment.

I think this diagram shows illustrates this concept clearly:

At the lower level, WSI would be limited to Core Wasm constructs, much like a minimal kernel interface. This keeps the implementation lightweight and ensures minimal performance overhead—critical for systems and embedded programming. The API surface would be small and map closely to functionality present in every major OS today.

At the higher level, the Component Model provides full expressivity, including rich types, async calling, a fully shared-nothing model, streams, futures, and more. Splitting these concerns allows for a cleaner design: for example, a low-level BSD-style socket API at the WSI later could coexist with a fully async wasi::sockets interface, similar to how Java and other ecosystems offer both low- and high-level abstractions. This enables developers to choose which option best suits their needs.

Regarding hand-crafted adapters, I agree that we should avoid them. The real issue is that WIT currently lacks the ability to represent Core Wasm imports and exports—something that is ultimately a tooling gap we can address.

As for reframing WSI as a WAMR project, I don’t believe that’s the right approach. I think that would presents a greater potential for fragmentation or a fork which I think we all wish to avoid.

Finally, on the topic of engineering resources, the engagement within e-SIG suggests strong interest in this approach. While engineering contributions aren’t guaranteed, the enthusiasm we've seen is encouraging. Moving forward will require work on tooling, interfaces, and SDKs (particularly WASI-LIBC), but the potential benefits make this a worthwhile direction.

[woodsmc]

Hey @lukewagner, @srberard - as @ospencer suggested this looks like a standards discussion, so we should move this to the SG.

Let's get this document merged, then prepare the simplified use case justification, and the following forward compatibility / roadmap technical note.

I think that would probably be the best way to expand upon this discussion, and as @ospencer reminded us, move it to the right venue.

It is a really interesting discussion, it would be interesting to see what others think about this too.

[lukewagner]

The real issue is that WIT currently lacks the ability to represent Core Wasm imports and exports—something that is ultimately a tooling gap we can address.

I don't think that's true; we should really try to bottom out on this since I think it's at the root of a lot of the misunderstanding here.

To provide some background: there are only two kinds of imports provided by the Component Model's Canonical ABI to core wasm:

• WIT-derived functions: core function imports that are derived mechanically from WIT function signatures via the Canonical ABI (this is probably what you're thinking about)
• Built-in functions: core function imports that are defined directly as core functions by the Canonical ABI with no associated WIT and that do not need to be imported by the outer component

Built-in functions give us the ability to craft custom ABIs and indeed that's what we're doing in 0.3 with the stream.read and stream.write built-ins, which take a pointer to caller-supplied memory that is held onto. I expect we'll add more built-ins for caller-supplied buffers and perhaps WAMR-style shared heaps.

However, we have to be very careful when adding built-in functions because they can't be sandboxed or virtualized; they're like wasm instructions (like memory.grow). Thus, if you look at the current list of built-ins, they adhere to the same capability-safety rules that Core WebAssembly adheres to by falling into one of 3 categories:

• They create something new and isolated (like core wasm memory or struct.new)
• They access something given to them via unforgeable handle (like core wasm struct.get or i32.load)
• They do something ambient that has no security implication (like core wasm atomic.fence)

Of course most I/O (filesystems, sockets, keyvalue, http, gpu, i2c, usb, ...) doesn't meet this criteria, and so for all these we need to use WIT interfaces that are explicitly imported by the component and are virtualizable. (And with the current and future set of built-ins, I think these WIT-defined interfaces can be sufficiently performant for all our embedded needs.)

By following these rules, we can get a lot of tangible benefits that are important to the folks working on the component model: sandboxing (supply-chain-attack resistance, principle of least authority, ...), safe host bindings, emulation for local testing, record-and-replay debugging, and bunch more automated tools.

When I look at the list of WSI interfaces in the above diagram, most of them do not meet the criteria for being built-ins. Thus, we can't simply say "the Component Model can treat all the WSI functions as built-in functions", because they break the key invariants we want from the Component Model. So if they are not built-in functions, they need to be WIT-derived functions, and if they don't use the Canonical ABI, then we'll need an adapter.

Regarding hand-crafted adapters, I agree that we should avoid them.

Hopefully the above explains why I think that either (1) we use the Canonical ABI for the WSI interfaces that can't be built-ins (which is most of them) or (2) we need an adapter. I'm not aware of a third option that doesn't break all the useful Component Model properties, but let me know if I'm missing something.

Again, if folks have short-term needs that can't wait for the Canonical ABI to improve, I think there's no problem designing an interim custom core wasm interface in WAMR that later we have to adapt to the Canonical ABI, but I don't think we should go through the expensive process of trying to standardize that if the goal is "short-term".

---

There's one other independent argument for why the Component Model can't be layered on WSI: native browser implementation. This is an important goal but browsers have clearly indicated that they are only open to natively implementing the Component Model (b/c, as I explained above, it adheres to the same rules as core wasm and doesn't "bake in I/O"). In contrast, there is little chance browsers would natively implement WSI, so if the Component Model were layered on WSI, that would knock out the Component Model. This is why WASI is layered on the Component Model, and not vice versa -- browsers can implement the Component Model natively (including the Built-in Functions, which would need to be implemented natively too) without implementing WASI (WASI would be polyfilled, even quite efficiently if we have a native Component Model implementation).

[lukewagner]

@woodsmc (Sorry, I didn't see your comment when replying) Discussing in the SG too sounds fine. Before merging, it would be good to see the basic comments in #10 fixed; as is, there haven't been any iterations since the original draft.

[srberard]

@lukewagner - Thank you for your explanation regarding what is available today with WIT. I agree that built-in functions need to be carefully constrained to maintain the security and virtualization properties of the Component Model. I’m not advocating that WSI functions be built-ins; I completely agree with your reasoning on that point. WSI functions should be defined formally in something like WIT. WITX offered this but had a number of shortcomings. Extending WIT to support expressing Core Wasm imports/exports would be a way to address this and something I would be open to. Again, the proposal is for WSI to be limited to Core Wasm only; hence these would need to be limited to Core Wasm constructs (and thus Core modules imports/exports)

Regarding browser implementations, I don’t see how WSI, expressed as Core Wasm imports/exports, would prevent browser implementations. Couldn’t a browser provide these interfaces directly or through an adapter, similar to other host functions.

+1 on discussing this in the SG

[lukewagner]

Extending WIT to support expressing Core Wasm imports/exports would be a way to address this and something I would be open to

Ah, this may be the key point: unfortunately only built-ins can have raw core wasm signatures. If we tried to add core function signatures to WIT, the problem we hit (concretely, already with WITX) is that almost all core functions depend on there being a single ambient shared memory and function-table. Once you depend on ambient shared memory/tables, the useful properties of component model are lost (security sandboxing, low-cost virtualization, simple automatic bindings, etc). By improving the Canonical ABI and the set of supporting built-ins—addressing performance cases where you'd otherwise want a core function in WIT—I don't think we'll need core functions in WIT. This is what I'd like to enumerate in a document and work through, because while there is a list, it's not a huge list.

Regarding browser implementations, I don’t see how WSI, expressed as Core Wasm imports/exports, would prevent browser implementations. Couldn’t a browser provide these interfaces directly or through an adapter, similar to other host functions.

Oops, sorry, I should have contextualized this by saying that this is a problem if WSI interfaces are to be treated as built-ins (due to their use of core function signatures that depend on sharing memory/tables).

[ttrenner]

@lukewagner @srberard I think, we come closer to more concrete action items.

If we tried to add core function signatures to WIT, the problem we hit (concretely, already with WITX) is that almost all core functions depend on there being a single ambient shared memory and function-table. Once you depend on ambient shared memory/tables, the useful properties of component model are lost (security sandboxing, low-cost virtualization, simple automatic bindings, etc).

I don't think we'll need core functions in WIT

I think, that in addition to saying that this and that is not working (due to cannibalizing CM's niceties) it would be good to sketch a concrete generally working proposal. I think, that it is near to impossible to think of all the future use cases that might come up. Just taking "stream" as an example: it adresses use cases for which sequential data exchange is sufficient. It seems to not be sufficient for random access data exchange. Another example, not dependent on CM yet: WAMR's shared heap: It addresses use cases, where "shared mem between wasm modules is needed", but does not address use cases where shared mem between wasm and another native process is needed.

So, a generally working concept would be great. I must admit, that I don't know whether this is possible at all. But you, @lukewagner, seem to be optimistic. So, maybe we as a community could - together - work out, how a concrete solution for optimizing performance with WIT/canon.ABI might look like. And once all agree on that general concept, we could try to share the burden of implementing it.

[lum1n0us]

Another example, not dependent on CM yet: WAMR's shared heap: It addresses use cases, where "shared mem between wasm modules is needed", but does not address use cases where shared mem between wasm and another native process is needed.

Apologies for any confusion caused. The original concept behind the shared heap was to allow a Wasm application to access a specific part (or the entirety, if trusted) of the host memory that lies outside the sandbox and may even be in different address spaces. It's somewhat akin to mapping a portion of the host memory into the Wasm world, thereby extending the linear memory defined by WebAssembly.

From another perspective, it can be seen as additional linear memories created by the host(like (memory $2), (memory $3)). If there were a usable toolchain that supported the multi-memory proposal, this shared-heap feature would be unnecessary and might not have been developed. Personally, I see it as a contingency for when there is a lack of spec support, and a product will find its own solution.

[lukewagner]

@ttrenner That sounds like a great next thing to work on together as a SIG. I'd be happy to iterate with everyone on such a goal-state document that addresses the use cases we have in mind. And you're right: 0.3 streams don't solve all the use cases; more is needed, so a great next step is to enumerate the remaining specific use cases and which specific additions (to WIT/CABI) would address them.

[woodsmc]

Hey Folks... since this is an E-SIG that will not be presented to the SG in it's current form, following @ospeencer 's suggestion, I'd like to set myself, and the document authors a challenge. Let's look to gather all feedback by Monday March 3rd close of business, US Pacific time. Then look to make sure that the document authors have addressed all the feedback by, say Thursday March 6th close of business pacific time. With a view to getting the document merged by end of the week next week.

Bit of a forcing function, but just so we don't spend too long on it, and move on to some of the constructive and exciting work we have in front of us.

Thoughts? Too short?

I set myself an aggressive timeline! - The document has done a great job at provoking discussion, and I want to say a huge thank you to everyone who has spent the time and energy to discuss this week. I know there has been hours spent writing replies here, but also time spent talking between each other via email and on the phone.

There are edits to do to the document on tone and pitch. There is no blame here. We are where we are. I'll go through the document on Monday to try to make sure this tone is corrected as per @abrown's welcome feedback.

With @ospencer feedback still think two more focused deliverables would be great. Perhaps one we can prepare for the next SG to detail the reasons why we need long term support for the 0.1 SDK and the need to add to it (but excluding how this will be done).

Then a second deliverable which would go in more detail on how the additions should be added to the SDK, and what this process might take.

I think this document (the one we are commenting on now) has by and large done it's job of provoking the discussion and getting us working and thinking together. I'd like to preserve it as an internal discussion document only. It still has a lot of value as an internal discussion document.

The next documents, particularly the second deliverable are going to be much more detailed and interesting.

[abrown]

It might also be helpful to mention here the plan Luke laid out for wasm32-wasip*-module. Seems like that would be something realistic that p1-style runtimes could adopt for running newer binaries on older runtimes?

[abrown]

Or see what I suggested below...

[abrown]

Suggested change

	The lack of a commitment to provide long term support for WASI 0.1 and the inability of WASI 0,1 runtimes to execute the newer binary formats produced by the WASI 0.2+ toolchains will result in leaving early adopters without a viable migration path. If left unaddressed this risks fragmenting the ecosystem and undermining trust in WASI’s long-term viability.
	The inability of WASI 0.1 runtimes to execute the newer binary formats produced by the WASI 0.2+ toolchains could result in leaving early adopters without a viable migration path. Without adopting a proposal like https://github.com/WebAssembly/component-model/pull/378 (or similar), this toolchain gap risks fragmenting the ecosystem and undermining trust in WASI’s long-term viability.

@woodsmc, what do you think of this? I'm trying to highlight that there are proposals out there that would resolve this issue — it might motivate someone to pick up a shovel to work on solving this.

[woodsmc]

Yes, it's a good idea (and sorry for the delay on this). In my original I was trying to highlight the urgency to step up. Let's me see if I can combine those two, like an enumerated (none-exhaustive) list of initial efforts.

[lukewagner]

Looking at the newer commits, I appreciate the work that has been done to nuance the original wording. Re-reading the document, I still see quite a few areas which, in describing the current state of affairs contain true pain points (that do warrant calls to action), but as part of generalized statements that require more work to nuance into accuracy. I expect each of these cases could be fixed with effort and discussion, like @abrown has already done in the areas improved already, but it'll take more time and effort, and I'm not sure if folks are up for it.

A second, issue is that, as we discussed in this comment thread that's still unresolved, I still haven't seen any argument for how there is a viable "layering" approach in a WASI standards context (in which the upper layer directly builds on and extends the lower layer). I can see both non-standard transitional approaches (that aren't layering) that look like the "WSI" described in the document as well as standards-based layering approaches that would allow a core wasm engines to support arbitrary components and implement WIT-defined interfaces with incremental effort that doesn't require understanding anything other than core wasm ABIs, but neither are what is in the document.

Again, I'm not sure how much work we want to do to get this document into a state that addresses these concerns; already I can tell that work has shifted to new documents (as suggested in the above comments) that enumerate concrete issues upon which we can iterate on standard, layerable technical solutions. I'd love to shift focus to these too, but I'm worried that publishing the document as-is will not sufficiently represent the "understanding at a point in time" nature of this document. To avoid the problems that arise from documents that may get taken for current fact in the absence of context, the W3C frames such documents with clearly-visible caveats (e.g.). So my ask would be that, if we want to merge this, we first do likewise. Or archiving the PR would be fine too, since it won't be lost.