search

WasmEdge / wasmedge-rust-sdk

Embed WasmEdge functions in a Rust host app
Apache License 2.0
30 stars 15 forks source link

We should remove wasinn feature flag in plugin.rs #78

Open CaptainVincent opened 1 year ago

CaptainVincent commented 1 year ago

Designing plugins to be dynamically loaded. Introducing feature flag make functionality is statically determined. Consider using a macro-like approach to dynamic generate the relevant preload API.

apepkuss commented 1 year ago

In the plugin mod (namely plugin.rs), the wasi_nn feature works as a switch to enable/disable the nn_preload API and the relevant types. The motivation of this design is from the C-API WasmEdge_PluginInitWASINN. As the description of the C-API, it is used to initialize the wasi_nn plug-in, implicitly meaning that it is only available when wasi_nn is enabled. Therefore, for the cases of the wasi_nn plugin being not present, the nn_preload API should not be present; when the wasi_nn plugin is required, users should explicitly enable the wasi_nn feature so that they can use the wasi_nn related APIs, such as the nn_preload API.

CaptainVincent commented 1 year ago

I'm wondering if support for wasi_nn should be dynamically determined? This is because it only makes sense when the plugin loader detects .so files related to wasi_nn. If it's solely determined by the rust feature flag but without a corresponding plugin library, it's still not meaningful. Is it feasible to optimize this by generating functions through macros only when the .so files are found? However, to be honest, I'm not sure about the complexity of this modification.