A Proposal to create a Sig Embedded #79
Conversation
docs: added GitHub handle
Fix some names of supporting members
Update affiliation
|
Great idea! I'd also like to take part in this. |
|
@squillace says LGTM! |
|
I think embedded devices are an important target for WebAssembly, so this is great. |
|
This is great! I also support this and would love to be involved. |
|
This is great! I also support this and am willing to participate in it. |
There was a problem hiding this comment.
Thanks for proposing this SIG!
The TSC discussed this proposal in our last meeting. We are excited, by the amount of people excited for this SIG! That said, we have a few suggestions (mostly nitpicks, inline below) we'd like to see addressed before we approve the proposal and merge this PR. In particular, we'd like to make explicit (it was kind of hiding implicitly in there) that the component model, WASI, and languange-agnostic WIT interfaces can help bring our Bytecode Alliance values (such as security, modularity, and language interoperability) to the embedded space.
Looking forward to this SIG! Thanks again for organizing around it.
On behalf of the TSC,
Nick Fitzgerald
|
|
||
| The Embedded ecosystem is ideally placed to benefit from the use of WASM and WASI. It has a set of constraints on performance in comparison to native non—WASM execution, determinism and reliability which can exceed those of other ecosystems. This gives rise to the definition of a low footprint device. The best way to address these specific needs is with a unified ecosystem of tools, technologies, documentation, and support. | ||
|
|
||
| The purpose of this group is to support and promote the use of WebAssembly and WASI in Embedded and Industrial user cases. This will be achieved by providing notes on best practice to existing practitioners, and by providing the TSC, WASI subgroup and WASM community group with uses cases which illustrate constraints and proposals to address such limitations. |
There was a problem hiding this comment.
| The purpose of this group is to support and promote the use of WebAssembly and WASI in Embedded and Industrial user cases. This will be achieved by providing notes on best practice to existing practitioners, and by providing the TSC, WASI subgroup and WASM community group with uses cases which illustrate constraints and proposals to address such limitations. | |
| The purpose of this group is to support and promote security, correctness, modularity, and language compatibility in the Embedded and Industrial ecosystem through the use of WebAssembly, WASI, the component model, and WIT interfaces. This will be achieved by providing notes on best practices to existing practitioners, and by gathering use cases and constraints of the embedded space to guide new proposals to address existing limitations. |
There was a problem hiding this comment.
The purpose of this group is to support and promote security, correctness, modularity, and language compatibility in the Embedded and Industrial ecosystem through the use of WebAssembly, WASI, the component model, and WIT interfaces.
I would like to say the purpose of this SIG would be to solve the requirements and problems for the embedded space to use WebAssembly.
There was a problem hiding this comment.
@xwang98 we discussed this quite a bit in the TSC, and Nick's suggested edit here is a result of that discussion.
The TSC is excited to support the creation of a SIG-Embedded, because we agree that there's significant value in bringing excellent Wasm support to the significant and compelling use cases the embedded space has.
What we want to see made explicit in the SIG's charter is something we of course all know: that as a Bytecode Alliance activity, the SIG needs to pursue the goals you mention in a way that supports the BA's mission. As included in Nick's edit, at the highest level that means promoting security, correctness, modularity, and language compatibility.
We also wanted to make more explicit something else that was already an implicit requirement in the description: that the SIG should base its designs on the Component Model and WIT. Because WASI is based on these foundations, that already was a requirement in the previous draft, but we wanted to make that more explicit to help people new to this space to more readily understand things.
There was a problem hiding this comment.
a couple of points, and I'm laying them out for suggestions how you would suggest we word this to be both clear and suggestive of what CAN be done.
- the point at which it is simply not worth it to use components, let alone webassembly, in favor of artisanal code (my phrase for "we're rolling our own assembler here, baby") is one of the dividing lines between "we are figuring out how we should do this with components" and "components have little to no benefit in this space". I believe that the overall objective is to drive components and the evolution of the model such that it can expand its utility as small and optimized as it can go before the benefits vanish. This might be seen as a "negative" statement, but I believe the major point is to bring components as far down as we can whilst being explicit about where the "utility event horizon" is.
- so I like the proposed wording change here in that it does say that, but I'd add the "utility event horizon" statement as well. Something like the last sentence satisfies that need to me.
If we just say "webassembly" and embedded/industrial, that's not driving components, which is the mission the BCA is here to support. So components -- which for me is shorthand for the security, correctness, modularity, and language compatibility of Nick's phrasing -- is front and center, knowing that there will always be some large swath of computing for which wasm is not appropriate. Write once, run 75% of the places. :-P
There was a problem hiding this comment.
Thanks for the comments! @tschneidereit @squillace
There is no any objection to components. I totally support the component, however, we still need to ensure the SIG has the flexibility to create the most appropriate solution for the real problems and requirements. There are quite some concerns about the side effects of component components in the embedded space. Let's drive the concerns in the SIG, maybe we can contribute to the component for the embedded. I am sure the component component will speak for itself.
There was a problem hiding this comment.
Oh, by the way, I think the lack of SDKs directly targeting preview2 without a component adapter is additionally slowing down p1 to p2 migration for embedded. Extracting core modules from components can easily be done using jco, if you still need some of your p1 tooling 😉
There was a problem hiding this comment.
I want to follow up again here because some of my own comments don't sit quite right with me after letting all of this percolate more.
Not asking for this would be a direct violation of the TSC's mandate, because it'd immediately run into conflict with our mission and operating principles.
This in particular I want to clarify: I fear it might easily be taken as me expressing fear that eSIG itself might violate the BA's principles and act against its mission. That is categorically not what I'm trying to say here; I was trying to explain the TSC's structural position in how the BA works, not indicate that I think violations are bound to happen and will need to be handled. My apologies for not being more clear on this very important point.
Another thing I have reflected on more and that I think is in need of clarification: from the TSC side we've focused on the Component Model, but really I think that's not the right focus, exactly. I think what we really want to ensure is that the in eSIG always be focused on standards-based approaches. Our hope is that the component model will go a very long way—perhaps all of the way—towards covering use cases pursued in eSIG. But yes, that might not be how things turn out, and other avenues might have to be pursued.
In case other approaches have to be pursued, I do think we should ensure strong communication between eSIG and the TSC when it comes to standardization approaches, venues to do this standardization in, etc. The way I interpret the TSC's mandate, that kind of decision should be made at this level to ensure a cohesive approach for the BA overall. I hope that that isn't all that controversial; it is something that hadn't fully crystalized for myself before.
And yet another thing to clarify: I don't think we have a full handle on all the ways the component model can be expressed. Above, @sunfishcode showed a way to target the canonical ABI, no binary components in sight. I think there's lots of potential for making such an approach very smooth. That could even involve making it part of a deployment pipeline instead of the authoring toolchain: that way everything up to deployment is fully standardized components, interoperable with other environments. It'd have the added benefit of retaining more information right up to the point where it's definitely not needed anymore.
(A downside is that it's limited to certain configurations of the canonical ABI, including lowerings to WebAssembly GC, but that's of course part-and-parcel in the embedded space. As discussed above, nobody expects every runtime targeting that space to be able to support the full generality of the component model, or even core WebAssembly.)
I hope these clarifications help make the TSC's position (or in some cases at least mine) clearer!
There was a problem hiding this comment.
@cpetig thank you for sharing your explorations and findings ❤️ I've long been interested in approaches like the ones you describe, including use of WIT interfaces in native code.
And I agree that WASI 0.2, and WIT based interfaces more generally, should be a great fit for the embedded space in various ways, and look forward to how things unfold on that point.
There was a problem hiding this comment.
WIT could be used to generate WITx and this would generate preview1 bindings.
I think we are in alignment on this point: I consider that described stack to be an implementation detail of using WIT-based (and therefore component model-based) APIs.
So I would be happy with the following wording, if we want to explicitly call out that approach as allowed:
New APIs must be based on the component model and its canonical ABI. These APIs may, as an implementation detail, also be rendered in ABI-compatible WITx that is suitable for p1 toolchains.
There was a problem hiding this comment.
Thank you to everyone that's contributed to the discussion so far. It's been lively, and I know a lot of energy has spent here. Thank you! - We've made a lot of progress, but there is still more to do. The discussion has seemed overlapping in places and I can see a number of discussions occurring at the same time:
- The text review of the proposed charter (the original purpose of the PR)
- An alignment discussion between expectations from the BCA and the needs of the embedded community
- General excitement for the SIG and some positive input on the prospects for the component model in the embedded space
- A request for help and long term support in future standard migrations
It’s hard / impossible to do all of this in a PR discussion. It really isn't designed for this. I'd like to take some time to catchup with the embedded folks that commented here, and I'd also like to take some time to explain some of the needs of the embedded ecosystem to the WASI subgroup; after all, this is community feedback. Explaining the needs of the embedded ecosystem and the issues / obstacles we currently see will go some way, I hope, to addressing the overlapping discussions we see here.
[edit: fixing type-o to reflect a presentation to the WASI subgroup, not the Wasm CG, at least, not yet anyway - thanks to @sunfishcode catching my type-o and letting me know]
|
|
||
| The purpose of this group is to support and promote the use of WebAssembly and WASI in Embedded and Industrial user cases. This will be achieved by providing notes on best practice to existing practitioners, and by providing the TSC, WASI subgroup and WASM community group with uses cases which illustrate constraints and proposals to address such limitations. | ||
|
|
||
| Any work the group does which involves standardized extensions to runtimes and their interfaces will enter the appropriate standardization process (e.g. WASM CG, WASI). |
There was a problem hiding this comment.
| Any work the group does which involves standardized extensions to runtimes and their interfaces will enter the appropriate standardization process (e.g. WASM CG, WASI). | |
| Any work the group does which involves changes to runtimes and their interfaces that are semantically visible to Wasm guests will enter the appropriate standardization process (e.g. the WebAssembly Community Group or its WASI subgroup). Major architectural changes to runtime internals (those not semantically visible to Wasm guests) will follow [the Bytecode Alliance RFC process](https://github.com/bytecodealliance/rfcs/blob/main/accepted/rfc-process.md). |
| 2. The group may provide notes and guides to the embedded community on how to address the specific constraints the ecosystem. | ||
| 3. The group may provide notes to the WASM CG, WASI CG on industrial uses cases and technical constraints. | ||
| 4. The group may provide notes and where appropriate technical proof of concepts to the WASM CG and WASI CG on ways to address the specific constraints faced by the Embedded and industrial use cases. | ||
| 5. The group may provide software to support embedded use cases including proof of concept implementations, producer tools, or proposed solutions, which may be specialized for specific use cases or platforms. |
There was a problem hiding this comment.
| 5. The group may provide software to support embedded use cases including proof of concept implementations, producer tools, or proposed solutions, which may be specialized for specific use cases or platforms. | |
| 5. The group may propose new Bytecode Alliance hosted projects to support embedded use cases including proof of concept implementations, producer tools, or proposed solutions, which may be specialized for specific use cases or platforms. |
There was a problem hiding this comment.
This would prevent contributions to existing software projects, some of which are already hosted by the bytecode alliance. As it only allows for "new" hosted projects. What if the SIG needed to contribute to an existing project? The WASI SDK, WAMR, or Wasmtime?
Is it really necessary to propose an entire project, in order to show a proof of concept solution to a technical constraint? - See point 4?. This wording would prevent the SIG from doing this.
This constraint appears quite limiting. Is there a specific concern the TSC has? - Perhaps you could elaborate, and we could address it together.
Edit: spelling.
There was a problem hiding this comment.
key word here, may. Does not say will, so I think its fine. I would also think we could add supportive wording: may propose new Bytecode Alliance hosted projects and may contribute features to existing Bytecode Alliance projects that support....
????
There was a problem hiding this comment.
My guess is that a LOT of wasi-virt things might come out of this, for example, let alone wasi proposals (wasi:usb/i2c,etc), which, by the way, I would assume qualifies us for "projects" in any case. Otherwise, we'll end up writing guidance for how wasm and component usage seems to have tradeoff event horizons for various use cases, and that's critical for new entrants into the ecosystem to think clearly more rapidly than those of us muddling our way through at the moment.....
What do you think? @fitzgen
There was a problem hiding this comment.
oooo and wasi-libc work.... frankly, I see this as DEFINITELY producing BCA project contributions at a minimum. the proposals that do not yet exist will be new, from my pov.
There was a problem hiding this comment.
oh for sure: we definitely don't want to forbid contributions to existing projects! The suggested edit was more about making explicit that new projects might come out of this work.
There was a problem hiding this comment.
Yeah the intention was definitely not to prohibit contributing to existing projects; just about the process for creating new projects.
For clarity, it might be easiest to split this into two bullet points: one for existing and one for new projects.
There was a problem hiding this comment.
I have a feeling that people do not currently KNOW what new projects will come out of this but I think proposals are definitely expected.
There was a problem hiding this comment.
Folks, this all sounds good. Great suggestion from @squillace and @fitzgen to clean this up with two bullet points:
- The group may contribute features to existing Bytecode Alliance projects that support embedded / industrial use cases including proof of concept implementations, producer tools or proposed solutions.
- The group may propose new Bytecode Alliance hosted projects to support embedded use cases including proof of concept implementations, producer tools, or proposed solutions, which may be specialized for specific use cases or platforms.
Co-authored-by: Nick Fitzgerald <fitzgen@gmail.com>
Co-authored-by: Nick Fitzgerald <fitzgen@gmail.com>
Co-authored-by: Nick Fitzgerald <fitzgen@gmail.com>
Co-authored-by: Nick Fitzgerald <fitzgen@gmail.com>
Co-authored-by: Nick Fitzgerald <fitzgen@gmail.com>
|
Sharing my enthusiasm for this proposal and place to drive the use of WebAssembly and WASI in the embedded space! Many of us have tried, failed and learned through experimentation over the last 6+ years and would love to work on this together as a community. The time is right ❤️ |
Add @penzn to SIG-embedded supporters
|
Perfect looking forward for the details |
|
Looks like some great discussions have been happening here. I had a good chat with @woodsmc the other day and I am in support of this SIG. Redpanda is by no means an embedded system, but it accepts many constraints that embedded devices have in order to increase performance (i.e. around memory fragmentation and limits). |
|
After a discussion with the TSC and members of the wider embedded community we will rework the charter and resubmit a new PR shortly. |
Hello folks, please accept this PR as a formal request to establish an embedded / Industrial IoT Special Interest Group. The proposal has generated a considerable amount of interest both inside the bytecode alliance and outside it. This might, potentially, lead to new members joining our Bytecode Alliance family. I’d be delighted to discuss the proposal in more detail at your convenience.