linux-kernel - Re: [PATCH v1 1/2] rust: time: Rename Delta's methods as_micros_ceil and as

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: <CANiq72kacWaLo=EE8WyA_M2Pr9h1MkqjeAmqet6CSGWLvM7B9g@mail.gmail.com>
Date: Thu, 19 Jun 2025 09:23:38 +0200
From: Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
To: FUJITA Tomonori <fujita.tomonori@...il.com>
Cc: aliceryhl@...gle.com, a.hindborg@...nel.org, alex.gaynor@...il.com, 
	ojeda@...nel.org, anna-maria@...utronix.de, bjorn3_gh@...tonmail.com, 
	boqun.feng@...il.com, dakr@...nel.org, frederic@...nel.org, gary@...yguo.net, 
	jstultz@...gle.com, linux-kernel@...r.kernel.org, lossin@...nel.org, 
	lyude@...hat.com, rust-for-linux@...r.kernel.org, sboyd@...nel.org, 
	tglx@...utronix.de, tmgross@...ch.edu
Subject: Re: [PATCH v1 1/2] rust: time: Rename Delta's methods as_micros_ceil
 and as_millis

On Thu, Jun 19, 2025 at 9:08 AM FUJITA Tomonori
<fujita.tomonori@...il.com> wrote:
>
> So would the function be defined like this?
>
> fn as_nanos(self) -> i64;
>
> If that's the case, then we've come full circle back to the original
> problem; Clippy warns against using as_* names for trait methods that
> take self as follows:
>
> warning: methods called `as_*` usually take `self` by reference or `self` by mutable reference

Yeah, the Clippy warning is indeed one more data point that the
guidelines are confusing to the point of having Clippy complain or,
more likely, the guidelines' intention is that we should just pick
`&self`.

If we decide to be OK with `self`s in the kernel for these cases, we
can simply disable the lint. Doing so means we lose the rest of the
checking for that lint, sadly.

And, yeah, we are indeed going in circles.

What I would normally suggest for cases like this is answering: what
would be the best for the kernel's particular case, regardless of
existing guidelines/lints? Then, if we think it is better to be
different, and there is enough justification to do so, then try to
mitigate the lose of the lints, talk to upstream, write our own
variation of the guidelines, etc.

So I would like to hear if anybody feels strongly about either
direction, i.e. any other pros/cons that we haven't thought of.

Thanks!

Cheers,
Miguel