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: <CANiq72k_=VRWDdZmai0BeN9PvoSXTrqv5CC9MgnCFV+rMMzLhQ@mail.gmail.com>
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ