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

[Boeuf, Sebastien]

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<mailto:slp at redhat.com>> wrote:


Paolo Bonzini <pbonzini at redhat.com<mailto: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.

Something we didn't talk about is the fact that we had some discussions a few weeks ago about putting those bindings into the virtio crate itself. I'm glad to see that everybody agrees (or don't disagree) with putting them inside their own crate, the same way it's already done for the kvm-bindings.
Crates are cheap, so I feel it's better if we can decouple things.
And one global comments is that we should follow the same pattern for any auto-generated binding we might add in the future, for the sake of being consistent.

Thanks,
Sebastien


Thanks,
Sergio.
_______________________________________________
Rust-vmm mailing list
Rust-vmm at lists.opendev.org<mailto:Rust-vmm at lists.opendev.org>
http://lists.opendev.org/cgi-bin/mailman/listinfo/rust-vmm


_______________________________________________

Rust-vmm mailing list

Rust-vmm at lists.opendev.org<mailto:Rust-vmm at lists.opendev.org>

http://lists.opendev.org/cgi-bin/mailman/listinfo/rust-vmm

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opendev.org/pipermail/rust-vmm/attachments/20190509/0f9382bf/attachment-0001.html>