Libvirt Rust bindings could use some work

[Daniel P. Berrangé]

On Mon, Feb 21, 2022 at 10:21:32AM -0500, Andrea Bolognani wrote:
> On Fri, Feb 18, 2022 at 10:28:29AM +0100, Wim de With wrote:
> > Hello,
> >
> > I was reading the Rust bindings for libvirt and I noticed that they are
> > not very idiomatic. A couple of examples:
> >
> > 1. It is conventional to have a *-sys crate containing only the C
> > interface and the linking configuration. The virt crate would then
> > depend on this libvirt-sys crate to implement a safe and ergonomic
> > wrapper.
> > 2. The API heavily uses integers to indicate flags. Sometimes those
> > integers are type aliased and sometimes they are not. In Rust, this can
> > be much nicer, using enums to represent only valid flags. The same
> > applies to some return values.
> > 3. Since libvirt is thread-safe, the Rust types could be Send and Sync,
> > so that they can also be used in a multithreaded context. Special care
> > needs to be taken with translating virGetLastError to Rust Results, but
> > it shouldn't be a problem.
> >
> > For a nice example of a Rust wrapper around a C library, see:
> > https://github.com/rust-lang/git2-rs
> >
> > I am willing to send some patches to fix some of these problems, but
> > this will almost certainly lead to breaking API changes, and I am not
> > sure what your opinion is on that.
> 
> 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.
> 
> 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.

Note that the auto-generating part in Go only applies to the very
low level shim in CGo, which was originally only needed to ensure
serialization for accessing thread locals errors, and now is
in progress of being repurposed as a dlopen layer.

The actual application facing APIs remain entirely hand written today.
This lets us expose APIs in a way that looks quite different from
the C where we have virTypedParameter APIs, and also where we have
event callbacks.

> > Finally, while I am not a legal expert, I believe that licensing a Rust
> > library as LGPL does not make much sense. Rust does not have a stable
> > ABI so everything is statically linked. This means that adding virt to a
> > Cargo.toml file of a non-GPL application is already in violation of the
> > license.

Yes, that is an unfortunate artifact of static linking.

> Licensing is a pretty fun minefield :)
> 
> For example, even though libvirt-rs itself would be statically linked
> into any application that uses it, by virtue of it being a wrapper
> around the C library you'd still end up dynamically linking against
> that.
> 
> I tend to agree that language bindings should follow the rest of the
> language ecosystem in terms of licensing, and for libvirt-rs
> specifically that would probably mean MIT. Perhaps we should consider
> looking into relicensing the project?

Since the intent of libvirt using LGPL was explicitly to allow non-GPL
compatible applications to use libvirt, it is a mistake to be using
a license that breaks this ability for Rust.

In Golang we've used MIT license

For Rust we should aim for whatever is most appropriate - MIT or BSD
or Apache - I'm not familiar with which is dominant in the Rust world.

The challenge will be getting copyright holder agreement. Sahid has
written the vast majority of the code, but has changed employers
a few times - most code was while he was at Red Hat, but some was
at Canonical.  The further complication is that French legal rules
often mean an employee retains copyright. To be safe we would need
to cover all possiblities and get explicit agreement from Sahid,
Canonical and Red Hat.  I can give approval on behalf of Red Hat.

Then there's a small number of other contributor who would need to
be found, or their contribution removed & re-written.

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 :|