ivila opened a new pull request, #296: URL: https://github.com/apache/teaclave-trustzone-sdk/pull/296
* Introduce `optee-teec-plugin-bindgen` crate to generate plugin bindings for plugin developers, replacing `optee-teec-macros`. * Refactor `optee-teec::PluginParameters` and add additional methods. * Update `optee-teec-sys::PluginMethod` to latest version. With these changes, plugin development now only requires adding `optee-teec-plugin-bindgen` as a build dependency and including the generated artifact in `lib.rs`. ## Why not use a proc macro? I have thought about implementing a `declare_supp_plugin` macro like this[demo](https://github.com/apache/teaclave-trustzone-sdk/compare/main...ivila:teaclave-trustzone-sdk:opt_plugin_0427): ```Rust declare_supp_plugin!( name: "my_plugin", uuid: "ef620757-fa2b-4f19-a1c4-6e51cfe4c0f9", init: my_init, invoke: my_invoke, ); ``` Developers can use it like: ```rust use optee_teec::{declare_supp_plugin, PluginParameters}; fn plugin_init() -> optee_teec::Result<()> { println!("*plugin*: init, version: {}", env!("CARGO_PKG_VERSION")); Ok(()) } fn plugin_invoke(_: &mut PluginParameters) -> optee_teec::Result<()> { println!("*plugin*: invoke"); Ok(()) } declare_supp_plugin!( name: "syslog", uuid: "ef620757-fa2b-4f19-a1c4-6e51cfe4c0f9", init: plugin_init, invoke: plugin_invoke, ); ``` The main issue is that developers may provide the UUID through a variable. Due to the limitations of proc macros, we cannot resolve the value of that variable during macro expansion. As a result, the UUID would need to be parsed and converted at runtime. ```Rust declare_supp_plugin!( name: "my_plugin", uuid: proto::PLUGIN_UUID, // proc_macro cannot resolve the value at compile time. init: my_init, invoke: my_invoke, ); ``` However, this introduces another problem: what happens if UUID parsing fails? Triggering a panic in a shared library is not a good idea and should be avoided. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
