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]
Message-ID: <20231027072621.03df3ec0@kernel.org>
Date: Fri, 27 Oct 2023 07:26:21 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
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, 27 Oct 2023 12:21:33 +0200 Miguel Ojeda wrote:
> And as I said when you told us that, that may be the right policy for
> C netdev, which has been around for a long time, has a well supported
> infrastructure, the code base is well-known, etc.
> 
> For Rust, it is not, for multiple reasons. For starters, we are not
> talking here about just another patch to your subsystem. This is a
> whole new subsystem API, in a new language, that needs careful design.
> Moreover, Rust abstractions are supposed to be "sound" (a property
> that C APIs do not need).

Nobody is questioning that.

> On top of that, two subsystems are reviewing it, and on our side we
> simply do not have the resources to commit to netdev review pace, as
> we told you privately. I am aware of at least 3 reviewers who have not
> had the time to look into the more recent versions yet, and it is
> unlikely they will have time before LPC. I would really recommend they
> are given the chance to give feedback.
> 
> So, if you appreciate/want/need our feedback, you will need to be a
> bit more patient.

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.

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?

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ