vhost-user-backend: simplify the use of generics

[Ablu]

In order to allow zero-cost exchanging of the concrete bitmap and vring
types, a lot of the generic code required using a tuple of
<VringType, BitmapType> for parameterizing the impl's. Once code is
also oblivious of the concrete backend (and a lot of code is), this
tuple turns into a triplet. Juggling these three single letter generic
parameters while making sure that all the type constraints (that are
also changing depending on the abstraction layer) does not feel very
ergonomic.

While one can argue that within this crate, this would be fine since
people probably know the internals, the design choice is leaking out
into every consumer of vhost-user-backend. Instead of just being able
to reference "some backend" one needs to copy a lot of boilerplate code
for also passing the other type parameters (again, while making sure
that all the constraints are met).

Instead, this commit changes things to utilize associated types [1].
This makes the Bitmap and Vring types part of the backend trait and
requires the implementations to spell them out. Code that just wants to
use the backend without needing to know the details can now just use
the trait without needing to specify the Bitmap and Vring types again.
Where needed, restricting Bitmap and Vring further is still possible
(though one no longer needs to copy all the existing restrictions and
can keep the code more maintainable by only listing new ones).

Overall, my main target was to improve the ergonomics of the consumers
of the crate. But I think the change also improves the readability and
maintainability within this crate. Combined, this hopefully justifies
the small code breakage in consumers.

No functional changes intended.
No change in type flexibility intended.

BREAKING CHANGE, consumers of the lib will need to adjust their code
(but it should improve the general readability).

Signed-off-by: Erik Schilling erik.schilling@linaro.org

[1] https://doc.rust-lang.org/book/ch19-03-advanced-traits.html#specifying-placeholder-types-in-trait-definitions-with-associated-types

Summary of the PR

Please summarize here why the changes in this PR are needed.

Requirements

Before submitting your PR, please make sure you addressed the following
requirements:

• All commits in this PR are signed (with git commit -s), and the commit
  message has max 60 characters for the summary and max 75 characters for each
  description line.
• All added/changed functionality has a corresponding unit/integration
  test.
• All added/changed public-facing functionality has entries in the "Upcoming
  Release" section of CHANGELOG.md (if no such section exists, please create one).
• Any newly added unsafe code is properly documented.

[Ablu]

CI seems to have timed out? Probably only needs a retrigger...

[jiangliu]

Once upon a time, we have struggled with rust generic associated types when developing the vm-memory crate, not sure about the latest progess about support of GAT. One good news is that vhost-user-backend is not as fundamental as vm-memory, so GAT may not be an issue for vhost-user-backend.

[Ablu]

@jiangliu hm, do you recall the concrete problems? Maybe it was with older rust versions? The only catch that I can think of is that you cannot use a normal generic type parameter in an associated type (I think that only works with dynamic dispatch). But that is a pretty weird case anyway (why not simply leave the type open then and set it on a higher level)?

[stsquad]

Do you have any examples of the conversion needed to show how its an improvement?

[Ablu]

@stsquad: The changes done to VhostUserHandler are probably a good hint at how things improve for consumers. Essentially, the number of generic arguments is simply reduced which makes them a lot saner to write. Right now, every time you want to pass a backend around, you will have to do so while juggling all these parameters (and copying the constraints all over the place).

I can draft a proposal how I was planning the simplify vhost-user in the next days.

[Ablu]

@stsquad here is an example train of thought for vhost-user:

1. Assume that we want to move the boilerplate around creating the daemon into a separate function (for example, in order to share it with the other daemons, or move it into some shared lib)
2. The code for that, right now, could look like: rust-vmm/vhost-device@a447db5
3. Forcing the user to spell out, for example, the full VringT type does not looks particulary helpful
4. Ablu/vhost-device@ed5cafb now show the changes necessary / possible with the associated type changes of this PR.
5. Mostly, one does not need to spell out ALL the requirements. One only needs to list what VhostUserDaemon puts on top of the VhostUserBackend. I also feel the associated types a bit easier to reason, given that they a) have more descriptive names, b) are immediately understood as types of the backend. Of course there may still be further room for improvement here, but I argue that the new code requires quite a few brain cycles less to process.

The benefits may be larger if code is generic over a VhostUserBackend, but does not need to fulfill further requirements (unlike what VhostUserDaemon demands here). In those cases the entire where could would probably become superfluous. However, I did not find code that uses things in vhost-device or virtiofsd.

Let me know if anything is unclear :).

[Ablu]

https://github.com/rust-vmm/vhost-device/pull/362/files#diff-1d8b7844066af51d6bb14aa4305e0bb53c38989c7d0da3a6765e50eccbee8e15 would be another example of code where this could simplify things.

[Ablu]

rebased

[stefano-garzarella]

@Ablu Sorry to just get here now, but I really like this cleanup!
It's going to be quite a change for our users, but I think it's worth it!

Would you like to rebase?
I hope this is the right release cycle to include this change.

[Ablu]

rebased

[stefano-garzarella]

LGTM, just some minor comments.

[Ablu]

Changelog

• added link to CHANGELOG
• fixed format woes

[stefano-garzarella]

@Ablu do you plan to work on https://github.com/rust-vmm/vhost-device Draft PR to be merged when we do the next release of this crate?

[Ablu]

@Ablu do you plan to work on https://github.com/rust-vmm/vhost-device Draft PR to be merged when we do the next release of this crate?

Will prepare one!

[Ablu]

Will prepare one!

rust-vmm/vhost-device#461

[stefano-garzarella]

@jiangliu @sboeuf you already approved a previous version, this one has only a few minimal changes, can you take a look again? Thanks ;-)