[Rust-VMM] Including a virtio-bindings crate in rust-vmm

[Sergio Lopez]

Boeuf, Sebastien <sebastien.boeuf at intel.com> writes:

> On Wed, 2019-05-08 at 22:38 +0800, Liu Jiang wrote:
>
>  On May 8, 2019, at 10:17 PM, Sergio Lopez <slp at redhat.com> wrote:
>
>  Paolo Bonzini <pbonzini at redhat.com> writes:
>
>  On 08/05/19 07:18, Sergio Lopez wrote:
>
>  Hi,
>
>  I think it'd be useful having a crate providing virtio bindgen-generated
>  bindings, similar to Firecracker's virtio_gen. I wrote one that provides
>  the same functionality, but with multiple versions mapped as features,
>  as kvm-bindings does:
>
>  https://git.sinrega.org/slp/virtio-bindings
>
>  Do you think we could make this a project under rust-vmm's umbrella?
>
>  Thanks,
>
>  Yes, I think so!  However, what is the reason to have anything but the
>  last version?  Headers from a newer kernel should be
>  backwards-compatible with code written for an older kernel.
>
>  The main reason is for that is allowing crate users to be able to do
>  strict size checks on structs.
>
>  As an example, virtio_blk_config was extended from 4.14 to 5.0 with new
>  fields. This structure may come as the payload a VhostUserConfig
>  message, and while you are able to just use the latest version and
>  accept any payload the same size or smaller, I think some users may want
>  to be more strict and just allow the expected size.
>
>  Given that the cost of maintaining the bindings is very small, I think
>  that's a use case we can afford supporting (and I volunteer for doing so
>  :-).
>
>  A hypervisor may support multiple kernel versions. So how about defining multiple data structure for different kernel versions? 
>  BTW, the auto-generated code has some useless code with poor readability.
>  It would be appreciated to manually maintain a beatified version:)
>
> The only concern with "beautified" version is that it needs more human maintenance. I'm not against it, but we need to find a real benefit to this.

I share the same opinion. The purpose of these bindings is getting
access to well-known and documented interfaces. The original sources can
be used as a reference.

Thanks,
Sergio.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <http://lists.opendev.org/pipermail/rust-vmm/attachments/20190509/2d64baf6/attachment.sig>