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
| ||
|
Message-ID: <ZTsbG7JMzBwcYzhy@Boquns-Mac-mini.home> Date: Thu, 26 Oct 2023 19:06:19 -0700 From: Boqun Feng <boqun.feng@...il.com> To: Andrew Lunn <andrew@...n.ch> Cc: Miguel Ojeda <miguel.ojeda.sandonis@...il.com>, 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 01:48:42AM +0200, Andrew Lunn wrote: > On Thu, Oct 26, 2023 at 12:39:46PM +0200, Miguel Ojeda wrote: > > On Thu, Oct 26, 2023 at 2:16 AM FUJITA Tomonori > > <fujita.tomonori@...il.com> wrote: > > > > > > This patchset adds Rust abstractions for phylib. It doesn't fully > > > cover the C APIs yet but I think that it's already useful. I implement > > > two PHY drivers (Asix AX88772A PHYs and Realtek Generic FE-GE). Seems > > > they work well with real hardware. > > > > This patch series has had 8 versions in a month. It would be better to > > wait more between revisions for this kind of patch series, especially > > when there is discussion still going on in the previous ones and it is > > a new "type" of code. > > That is actually about right for netdev. As i said, netdev moves fast, > review comments are expected within about 3 days. We also say don't > post a new version within 24 hours. So that gives you an idea of the > min and max. > > It is however good to let discussion reach some sort of conclusion, > but that also requires prompt discussion. And if that discussion is > not prompt, posting a new version is a way to kick reviewers into > action. > I wonder whether that actually helps, if a reviewer takes average four days to review a version (wants to give accurate comments and doesn't work on this full time), and the developer send a new version every three days, there is no possible way for the developer to get the reviews. (Honestly, if people could reach out to a conclusion for anything in three days, the world would be a much more peaceful place ;-)) Regards, Boqun > Andrew >
Powered by blists - more mailing lists