WASI预览2是officially released。
随着预览2的发布，预览1将被弃用并在各种工具中过渡到遗留支持。例如，documentation for wasmtime表示在预览2落地后的2个发布版本后，将删除遗留代码。
WASI预览1和预览2之间的主要区别是：
- 基于能力的安全性:WASI预览2引入了基于能力的安全原则，使用Wasm组件模型提供的设施。所有对外部资源的访问都由能力提供。组件模型类型系统中定义的句柄动态识别并提供对资源的访问。
- 模块化:WASI预览2使用组件模型的世界机制，允许描述特定一组API,以满足不同环境的需求。
- 新的接口定义:对于熟悉WASI预览1的人来说，接口已经适应使用Component Model定义的高级别类型，并使用WIT进行定义，包括WASI IO、Filesystem、Clocks和Random。一个WIT包是WIT接口和世界的集合。世界是对组件的导入和导出的一个完整描述，可以用于表示组件的执行环境。
当我们获得稳定的GOOS=wasip2时，我们可能需要考虑在未来的Go版本中淘汰(或移除)wasip1的方法。
应该有可能"bridge"预览1和预览2,使得预览1的程序仍然可以在预览2上运行。
这个问题现在跟踪有关新端口的讨论和功能请求。
相关问题
GOOS=wasip1 tracking issue
cc @golang/wasm
9条答案
按热度按时间k2arahey1#
我有点困惑，这个问题是否应该跟踪讨论如何实现这个支持的单独提案？我不知道问题是进行这些讨论的最佳地点(这里有很多探索要做)。这看起来不像一个提案。你为什么要添加提案标签？
关于潜在的wasip2/wasm端口用于Go,这是我和其他为Go中的WebAssembly端口做出贡献的人正在努力实现的事情，但我们还没有准备好提出提案。如果你想帮助解决这个问题，Gophers slack上的#webassembly频道是一个很好的讨论地方。
jyztefdp2#
It was a bit naive of mine to mark this as a proposal, I understand the complexity and work necessary to implement preview2 and I agree that the bulk of the discussion should happen somewhere else. My intention was to raise the awareness to the release and create some kind of umbrella issue regarding the new port, but maybe it is too early to do so.
Maybe we can keep this open as a feature request and use it for updates or community feedback/request while the wasm team works towards a proposal?
vshtjzan3#
感谢您的提问。根据我们的wasip1实现，您能估计需要完成多少工作吗？谢谢。
4nkexdtk4#
@cherrymui 的一些背景信息：
WASI Preview 2 建立在 Component Model 上，它引入了一个与 WASI Preview 1 的 C 风格 Core WebAssembly 调用约定不同的 new ABI。
我们应该将
GOARCH=wasm32和go:wasmexport提案视为GOOS=wasip2移植的先决条件：我们中的一些人一直在努力在 TinyGo 中实现
GOOS=wasip2,并为 WIT IDL 文件生成必要的 Go 代码。当前为
wasi:cli/command生成的 Go 绑定可以在这里找到：https://pkg.go.dev/github.com/ydnar/wasm-tools-go/wasi。生成此工具的wit-bindgen-go旨在输出适合包含在 Go 标准库中的代码，例如syscall/wasm/wasi。kcrjzv8t5#
支持
GOOS=wasip2的另一个可能需求是工具，特别是 Go 工具链是否能够原生输出一个 WebAssembly 组件，这与核心 Wasm 模块有所不同。目前，WIP TinyGo 端口为
wasip2使用的是wasm-tools在 TinyGo 编译器(wasm-tools component embed和wasm-tools component new)输出的编译后的 Wasm 模块上执行两个后处理步骤：今天早上在 Bytecode Alliance Go SIG 会议上讨论了这个问题。共识是 Go 应该能够原生发出一个组件，而不是依赖于外部程序(例如
wasm-tools)。yv5phkfx6#
感谢Randy提出这个问题，我也考虑过这个问题(参见#65199(评论))。我同意
wasip2/wasm的输出应该是一个Wasm组件，因为操作系统是明确的WASI p2,而不是一些通用的Wasm环境。到目前为止，我还不清楚Go是否有任何用例来输出Wasm核心模块。b4lqfgs47#
我曾经是一个WASIp2的狂热爱好者，但现在不再如此。https://kerkour.com/webassembly-wasi-preview2由@sylvain101010总结了我的担忧。
wwodge7n8#
这个recent announcement看起来非常有前途，可以与tinygo一起使用。事实上，我认为在这个帖子中的一些人甚至参与了其中。恭喜！
所以，我想知道这个问题是否会继续推进，以便为Go带来更广泛的wasip2支持？
irtuqstp9#
一群感兴趣的个人正在努力实现wasip2,但其先决条件包括#63131、#65199(开发中)和#66984(审查中)。一旦这些被接受并实施，我们可能能够提出一个wasip2提案。如果你想为此努力贡献，你可以阅读问题和相关的CLs,并在Gophers slack的#webassembly中加入讨论。请记住，所有Go中的webassembly工作都是由志愿者设计和实现的，而不是Go团队，因此时间表取决于志愿者的可用性。