netdev - Re: [PATCH net-next v7 0/5] Rust abstractions for network PHY drivers

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Fri, 27 Oct 2023 18:36:32 +0200
From: Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
To: Jakub Kicinski <kuba@...nel.org>
Cc: Andrew Lunn <andrew@...n.ch>, FUJITA Tomonori <fujita.tomonori@...il.com>, netdev@...r.kernel.org, 
	rust-for-linux@...r.kernel.org, tmgross@...ch.edu, benno.lossin@...ton.me, 
	wedsonaf@...il.com
Subject: Re: [PATCH net-next v7 0/5] Rust abstractions for network PHY drivers

On Fri, Oct 27, 2023 at 4:26 PM Jakub Kicinski <kuba@...nel.org> wrote:
>
> To be sure our process is not misunderstood - it's not about impatience
> (🥴️) or some rules we made up.  We get slightly over 100 patches a day
> (for us to apply, not subtrees). Longer review cycles would make keeping
> track of patches and discussions unmanageable.

Of course -- that is completely understandable. We are not trying to
change how netdev works. If you have some policies they are probably
the best for your situation.

To be clear, we are not the ones that want to upstream this code. In
fact, we have other items that have higher priority for us. But
Tomonori submitted this, and now we are being told that the Rust
subsystem somehow has to provide reviews within days. We cannot commit
to that, and that is what we told Andrew privately.

In addition, for Rust, we are trying to get the very first
abstractions that get into mainline as reasonably well-designed as we
can (and ideally "sound"), so that they can serve as an example. This
takes time, and typically several iterations.

> Is the expectation that over time you'll be less and less involved
> in particular subsystems? What's the patch volume right now for Rust?

Indeed, the plan is that eventually each subsystem handles Rust like
any other thing. Otherwise, it does not scale.

In fact, the sooner that happens, the better, but we would like to
have some consistency and getting people on the same page around what
is expected from Rust code and abstractions. This also takes time,
because it means typically talking and discussing with people.

For instance, as a trivial example, Andrew raised the maximum length
of a line in one of the last messages. We would like to avoid this
kind of difference between parts of the kernel -- it is the only
chance we will get, and there is really no reason to be inconsistent
(ideally, even automated, where possible).

Now, if netdev is extremely busy, then precisely because of that, it
may be a good idea to take the Rust stuff slowly, so that, by the time
it is in, you can actually handle any patches swiftly without having
to wait on us.

Cheers,
Miguel