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:41:09 +0200
From: Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
To: Andrew Lunn <andrew@...n.ch>
Cc: Boqun Feng <boqun.feng@...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 4:26 PM Andrew Lunn <andrew@...n.ch> wrote:
>
> Without seeing the user, you cannot say if the API makes sense.

(snip)

We are aware of all that, thank you.

But I am not sure what you are trying to point out. If I understand
correctly, Boqun was just suggesting an idea to split the pace, not
disputing the value of the rule or asking why it is in place.

> But this API unstableness plays both ways. You don't need a perfect
> API before it is merged. You just need it good enough. You can keep
> working on it once its merged.

Indeed, but there is no rush to put things in either. And for us,
"good enough" so far (i.e. for the very first abstractions), means
"everyone is in on the same page, no known soundness issues,
well-designed API that can serve as an example, enough time to review,
etc.".

In other words, we are trying to build consensus, not just put code
into the kernel.

> If you missed something which makes is
> unsound, not a problem, its just a bug, fix it an move on, like any
> other bug.

Sure, as long as you consider them stable-worthy issues and are happy
taking patches that may need to substantially change an API to fix the
unsoundness in some cases, that is fine.

Cheers,
Miguel