Hi,

This RFC proposes a minimal set of Rust networking abstractions for
link-type drivers, together with a Rust implementation of nlmon as a
reference driver.

The scope is intentionally narrow. The series only tries to cover the
pieces needed to model:

- rtnl link registration and validation
- net_device private state allocation
- sk_buff transmit ownership
- netlink tap lifetime management
- per-device stats updates

nlmon is a useful target for this because it is small, self-contained,
and exercises rtnl registration, netdevice setup, tap lifecycle, and
stats handling without introducing hardware-specific probe or teardown
paths.

The series is structured as follows:

- patches 1-2 expose the required bindings and helper glue
- patches 3-4 add the minimal Rust net abstractions
- patch 5 adds the Rust nlmon reference driver
- patch 6 adds scoped MAINTAINERS entries

The driver itself is built with #![forbid(unsafe_code)] and does not
call raw bindings directly. Unsafe is confined to small abstraction
implementations under rust/kernel/net/.

Validation so far:

- drivers/net/nlmon_rust.o builds successfully
- x86_64 bzImage builds successfully
- QEMU smoke passes:
  ip link add nlmon0 type nlmon
  ip link set nlmon0 up
  ip link show nlmon0
  ip link set nlmon0 down
  ip link del nlmon0

The Rust implementation is kept behind CONFIG_NLMON_RUST so the new
abstractions and the reference driver can be reviewed without displacing
the existing C implementation.

Feedback on the abstraction shape, the lifetime model, and whether
nlmon is a suitable reference driver would be especially appreciated.

I would also be grateful for guidance on any aspect of this series that
does not match Rust-for-Linux or netdev expectations. If the direction
is useful but the submission, factoring, or abstraction boundary needs
to change, I am happy to revise the series accordingly and resubmit.

Thanks,
Wenzhao Liao

Wenzhao Liao (6):
  rust: bindings: expose networking headers needed by nlmon
  rust: helpers: add net_device and sk_buff helper wrappers
  rust: net: add minimal skbuff, netdevice, and stats abstractions
  rust: net: add minimal rtnl registration and netlink tap support
  net: add Rust reference driver for nlmon
  MAINTAINERS: add Rust net and nlmon entries

 MAINTAINERS                     |  19 ++
 drivers/net/Kconfig             |   9 +
 drivers/net/Makefile            |   6 +-
 drivers/net/nlmon_rust.rs       |  93 ++++++++++
 rust/bindings/bindings_helper.h |   4 +
 rust/helpers/helpers.c          |   1 +
 rust/helpers/net.c              |  19 ++
 rust/kernel/net.rs              |   5 +
 rust/kernel/net/netdevice.rs    | 319 ++++++++++++++++++++++++++++++++
 rust/kernel/net/netlink_tap.rs  |  89 +++++++++
 rust/kernel/net/rtnl.rs         | 221 ++++++++++++++++++++++
 rust/kernel/net/skbuff.rs       |  67 +++++++
 rust/kernel/net/stats.rs        |  17 ++
 13 files changed, 868 insertions(+), 1 deletion(-)
 create mode 100644 drivers/net/nlmon_rust.rs
 create mode 100644 rust/helpers/net.c
 create mode 100644 rust/kernel/net/netdevice.rs
 create mode 100644 rust/kernel/net/netlink_tap.rs
 create mode 100644 rust/kernel/net/rtnl.rs
 create mode 100644 rust/kernel/net/skbuff.rs
 create mode 100644 rust/kernel/net/stats.rs

-- 
2.34.1

On Thu, Apr 02, 2026 at 12:36:34PM -0400, Wenzhao Liao wrote:
> Hi,
> 
> This RFC proposes a minimal set of Rust networking abstractions for
> link-type drivers, together with a Rust implementation of nlmon as a
> reference driver.

nlmon exists. Why would we want a second implementation in Rust?

It seems like we keep getting Rust submissions for the sake of
submitting Rust. We never seem to get Rust code adding something new,
something which does not already exist.

Please, if you want to submit Rust code, find a device which does not
have a driver and write a driver for it, in Rust. Or find a protocol
described in an RFC which we don't implement, and write a Rust
implementation. Or find a new firewall rule which cannot be described
using the current code, and implement it in Rust.

Unless it is something new, i doubt it will get accepted.

       Andrew