Is the plugin mechanism stable across Rust compiler versions?

[anelson]

I saw this project on the Console mailing list, and was intrigued by the fact that you have a Rust plugin model that appears not to use WASM. So I looked into how you did it and see that this is the key:

https://github.com/triyanox/lla/blob/0275f0efb4e02ef695a105128c37e1dc5a7f3d07/lla_plugin_interface/src/lib.rs#L41-L49

I'm curious, how did you make this stable across Rust compiler versions? Trait vtables specifically and the Rust ABI in general is not stable across compiler versions, so unless all plugins as well as the main executable are all compiled with exactly the same Rust compiler version on the same platform, making calls into that dyn Trait pointer can cause UB. Am I missing some secret sauce?

[chaqchase]

Hi there @anelson ! Thank you for taking the time to start this discussion much appreciate due to the fact that I was considering other alternatives for the current plugins implementation. The current plugin system uses a simple macro to generate a C-compatible constructor for plugins, but it does not inherently solve the ABI stability issue with trait objects. The approach relies on compiling plugins and the main application with the same Rust toolchain, which mitigates but does not completely eliminate potential undefined behavior due to trait vtable instability and this put some of the compatibility burdens on the end user.
For the future versions I've investigated three methods, the first is explicit FFI but turns out to add a lot of complexity, now I'm between using a serialization-based method this will expand the languages which plugins can be written in but I'm likely going to use a WASM based approach because it checks all the boxes.
What do you think? And if you have a better suggestion please do share !

[anelson]

The approach of hosting a WASM runtime with serialization into and out of the plugin is the only thing I've found that's sufficiently flexible and reliable while being reasonably low-effort, but it comes with significant limitations particularly around performance and flexibility which is why I was hopeful that maybe you'd found some secret handshake to host native Rust plugins w/o the downsides :)

A thousand years ago when I was starting my career, Windows had a cross-language object-oriented component mechanism called COM, which for a while was The Way in Windows to extend Windows components like Explorer and tools like Word with third-party code. One of the many reasons why it was such a nightmare was that it had to solve the problem of how to free memory in the host that was allocated in a plugin, or vice versa. Even if the ABI issue were solved, you'd still have memory management to worry about, and COM's solution was incredibly easy to mess up, leading to heap corruption and UB. Sadly I don't think solving this in a general way while keeping all of the Rust ergonomics and affordances is likely, so WASM seems like the way forward.

Perhaps over time WASI will mature and it will be possible to meaningfully interact with host hardware from within WASM. For now, as far as I'm aware the state of the art in WASM plugins in a Rust project is Zellij plugins, and no offense to the developers of Zellij but that is damning with faint praise ;)

One other approach I have toyed with is hosting the Lua runtime in Rust, exposing Rust functions to Lua for performance-critical tasks. This is by no means a silver bullet, it comes with significant downsides and is labor-intensive, but in my opinion it ends up putting less burden on the plugin authors (assuming they like writing Lua code).

[chaqchase]

Hey there @anelson ! Just wanted to let you know I've shipped v0.3.0 which tackles those ABI compatibility issues we chatted about. After playing around with different approaches and mulling over your insights about COM's memory management challenges, I found a way forward that doesn't need WASM after all. The new system uses C-compatible ABI throughout the plugin interfaces instead of relying on Rust's unstable trait vtables. I've been really careful about memory management, making sure ownership is crystal clear across FFI boundaries. For passing data between host and plugins, I went with Protocol Buffers – it's been great for maintaining compatibility both ways. There's also some version checking now to keep incompatible plugins from loading, plus better error handling when things go sideways during plugin loading. The only downside is that writing plugins takes a bit more code than before, but I think the extra stability and safety make it worthwhile. I'd love to hear what you think about this approach. It might not be as slick as WASM, but I feel like it hits a nice balance between keeping things stable and maintaining native performance. Now that the plugin system is stable, I'll be focusing on making plugin implementation simpler and more streamlined in future releases.

[anelson]

Nice! Clever workaround! We use Protobuf extensively in my day job, the Rust support via prost is great. The thing I don't like is that if you are going to define the interface types with .proto files, you now have a dependency on protoc. My advice would be to make sure that you generate those bindings in CI or some other automated step, and include the generated Rust bindings in source control and in the published crate so that building your binary and plugins doesn't require protoc.

I notice you're using a handle_request entrypoint for the FFI, that just takes a slice. I assume you'll define a message with a oneof field in Protobuf that will represent the various possible requests, and then use that to dispatch calls to specific Rust methods in the plugin for each request type. Ideally you'd hide as much of the protobuf-isms as possible, like the fact that oneof fields are always Option<T> to allow for the possibility that a new enum variant was added that wasn't known at the time the decoding code was compiled.

I like this better than WASM, especially for such a low-level tool like this. It would piss me off if I run ls and this takes several seconds to initialize some runtime and call out to a bunch of WASM plugins :) Plus this way plugins have complete access to the running system and any available APIs

[chaqchase]

Thanks for the fantastic feedback @anelson! I like your suggestion about generating protobuf bindings in CI and including them in source control - that's definitely going to make things smoother for plugin developers. I'll work on implementing this soon to hide all those protobuf complexities under the hood. And yeah, really glad we went this route instead of WASM for keeping things fast and flexible, while WASM is a neat concept, those cold starts would make lla painfully slow.
For future releases, I'm planning to make plugin implementation more streamlined and less verbose too because at the moment the plugin implementation requires more boilerplate than before so it will be great to make plugin developers write less code.