Libvirt Rust bindings could use some work

Daniel P. Berrangé berrange at redhat.com
Mon Feb 21 16:38:08 UTC 2022


On Mon, Feb 21, 2022 at 05:28:24PM +0100, Wim de With wrote:
> On Mon, Feb 21, 2022 at 10:21:32AM -0500, Andrea Bolognani wrote:
> > We are aware of the issues with the current API of libvirt-rs, but
> > unfortunately nobody has been able to dedicate time to addressing
> > them. Any contributions towards that goal that you or anyone else
> > could make would certainly be greatly appreciated!
> > 
> > Breaking the API should be fine I think. The current version number
> > is 0.2.11, so there shouldn't be any expectation in terms of API
> > stability.
> 
> I realized that GitLab is nowadays used for communication so I made more
> specific issues there. Do you prefer merge requests there or patches on
> the mailing list?

Merge requests exclusively for anything other than libvirt.git

> > Note that libvirt-python is mostly autogenerated, and there is an
> > ongoing effort to make the same happen for libvirt-go-module. Ideally
> > libvirt-rust would also follow this trend and end up with very little
> > manually-written code in it.
> 
> I've done some experiments here with bindgen, and it is pretty
> straightforward to generate FFI bindings using it. The problem is that
> generating safe idiomatic Rust wrappers on top of these bindings is
> non-trivial. Still, most wrapper functions will probably follow the same
> pattern, so it may be useful to investigate if macros could be used to
> make it easier to add new functions.
> 
> >From looking at the Git diff from v2.5.0 to v8.0.0, the libvirt API
> doesn't seem to change that often. Almost all changes consist of adding
> new enum variants and some new functions. Am I correct in assuming that
> an application that was written for v2.5.0 would still work with v8.0.0?

Correct, libvirt never knowingly breaks API compatibility. The API
is strictly append-only.

> To me it seems the best course of action would be to pick some minimum
> version of libvirt to support, and make sure that the Rust API wraps all
> functions there. From that point, adding functions and enum variants
> introduced in later versions of libvirt can be incremental changes and
> will (hopefully) be fairly easy to add. Rust has the concept of features
> to enable conditional compiling of those functions and enum variants
> only when the underlying libvirt supports them.

Conditional compilation is what we do in Go / Python bindings too.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|




More information about the libvir-list mailing list