mbox series

[v2,0/2] rust: virtio: add virtio support

Message ID 20230405201416.395840-1-daniel.almeida@collabora.com
Headers
Series rust: virtio: add virtio support |

Message

Daniel Almeida April 5, 2023, 8:14 p.m. UTC 
  This used to be a single patch, but I split it into two with the
addition of struct Scatterlist.

Again a bit new with Rust submissions. I was told by Gary Guo to
rebase on top of rust-next, but it seems *very* behind?

The first patch does not build on its own due to a dead_code warning.
It is hard to not have dead code when one is adding infrastructure to be
used by others at a later opportunity. Let me know if you would like to
see the patches squashed into one to fix this.

As suggested by Bjorn, I added a small virtio-entropy based sample.
It is a very bare-bones clone of virtio-rng.c that only sends a
single request.

Changes from v1:

- Addressed review comments by Miguel and Bjorn.
- Added a scatterlist abstraction
- Added a virtio-rng based sample

Daniel Almeida (2):
  rust: add scatterlist support
  rust: virtio: add virtio support

 rust/bindings/bindings_helper.h |   3 +
 rust/helpers.c                  |  25 +++
 rust/kernel/lib.rs              |   3 +
 rust/kernel/scatterlist.rs      |  40 +++++
 rust/kernel/virtio.rs           | 261 ++++++++++++++++++++++++++++++++
 rust/kernel/virtio/virtqueue.rs | 126 +++++++++++++++
 samples/rust/Kconfig            |  10 ++
 samples/rust/Makefile           |   1 +
 samples/rust/rust_virtio.rs     | 195 ++++++++++++++++++++++++
 9 files changed, 664 insertions(+)
 create mode 100644 rust/kernel/scatterlist.rs
 create mode 100644 rust/kernel/virtio.rs
 create mode 100644 rust/kernel/virtio/virtqueue.rs
 create mode 100644 samples/rust/rust_virtio.rs

Comments

Miguel Ojeda April 5, 2023, 11:19 p.m. UTC | #1 
Hi Daniel,

On Wed, Apr 5, 2023 at 10:14 PM Daniel Almeida
<daniel.almeida@collabora.com> wrote:
>
> Again a bit new with Rust submissions. I was told by Gary Guo to
> rebase on top of rust-next, but it seems *very* behind?

In general, prefer the most stable base you can find: Linus' tags if
possible, otherwise `rust-next` if you need something from there,
otherwise you may send something on top of some prerequisites that may
not have landed yet. Please see
https://rust-for-linux.com/contributing#the-rust-subsystem for some
other details. `rust-next` is the latest Rust state (which at the
moment is just Linus' -rc1 -- did you need something that landed later
in mainline? In any case, tomorrow I will likely move it to -rc5 since
I will start merging).

> The first patch does not build on its own due to a dead_code warning.
> It is hard to not have dead code when one is adding infrastructure to be
> used by others at a later opportunity. Let me know if you would like to
> see the patches squashed into one to fix this.

Patches series must build between each patch. However, instead of
squashing, you may use `allow(dead_code)` to split patches as they
would normally be split. In other words, it is more important to have
patches more easily reviewable than avoiding an `allow` line.

Cheers,
Miguel