linux-kernel - Re: [PATCH] Introduce Tyr

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 for Android: free password hash cracker in your pocket

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

Message-Id: <5F5F10F8-C082-44AA-9126-3436E14D0855@collabora.com>
Date: Mon, 30 Jun 2025 12:22:52 -0300
From: Daniel Almeida <daniel.almeida@...labora.com>
To: Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
Cc: Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
 Maxime Ripard <mripard@...nel.org>,
 Thomas Zimmermann <tzimmermann@...e.de>,
 David Airlie <airlied@...il.com>,
 Simona Vetter <simona@...ll.ch>,
 Miguel Ojeda <ojeda@...nel.org>,
 Alex Gaynor <alex.gaynor@...il.com>,
 Boqun Feng <boqun.feng@...il.com>,
 Gary Guo <gary@...yguo.net>,
 Björn Roy Baron <bjorn3_gh@...tonmail.com>,
 Benno Lossin <lossin@...nel.org>,
 Andreas Hindborg <a.hindborg@...nel.org>,
 Alice Ryhl <aliceryhl@...gle.com>,
 Trevor Gross <tmgross@...ch.edu>,
 Danilo Krummrich <dakr@...nel.org>,
 Daniel Stone <daniels@...labora.com>,
 Rob Herring <robh@...nel.org>,
 Alice Ryhl <alice.ryhl@...gle.com>,
 Beata Michalska <beata.michalska@....com>,
 Carsten Haitzler <carsten.haitzler@...s.arm.com>,
 Boris Brezillon <boris.brezillon@...labora.com>,
 Ashley Smith <ashley.smith@...labora.com>,
 linux-kernel@...r.kernel.org,
 dri-devel@...ts.freedesktop.org,
 rust-for-linux@...r.kernel.org,
 kernel@...labora.com
Subject: Re: [PATCH] Introduce Tyr

Hi Miguel,

>> Hmm, I must say I did not know that this was a thing.
>> 
>> Why is it better than [#allow] during the development phase?
> 
> I have some notes at:
> 
>    https://docs.kernel.org/rust/coding-guidelines.html#lints
> 
> Generally speaking, we default to `expect` unless there is a reason
> not to (I list some possible reasons in the link), because `expect`
> forces us to clean it when unneeded.
> 
> Not sure what you mean by "development phase" -- even if Tyr is under
> development, it should still try to conform to the usual guidelines.
> Of course, if a particular `expect` would be a pain, then please feel
> free to use `allow`. But is that case here? i.e. you will want to
> remove the `allow` anyway when you add the new code, no?
> 
> Thanks!
> 
> Cheers,
> Miguel

When I said "in development"I was referring to "dead_code" specifically, as we
will invariably have some of that until the other parts of the driver land.

Just as an example: IMHO it doesn't make much sense to only introduce the
register definitions used for this patch if we know for sure that:

a) the currently unused definitions will be used once the subsequent parts land,

b) they will not change, as they're derived from the hardware itself

It makes more sense to just sit down and transcribe this part of the spec at
once. It lowers the chance of copy and paste errors too.

As I said, I was unfamiliar with "expect". Can it be made to work on a module
level? Anyway, I can try to make this work with "expect" instead of “allow", no
worries :)

— Daniel