rust-for-linux.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>
To: FUJITA Tomonori <fujita.tomonori@gmail.com>
Cc: aliceryhl@google.com, a.hindborg@kernel.org,
	alex.gaynor@gmail.com,  ojeda@kernel.org,
	anna-maria@linutronix.de, bjorn3_gh@protonmail.com,
	 boqun.feng@gmail.com, dakr@kernel.org, frederic@kernel.org,
	gary@garyguo.net,  jstultz@google.com,
	linux-kernel@vger.kernel.org, lossin@kernel.org,
	 lyude@redhat.com, rust-for-linux@vger.kernel.org,
	sboyd@kernel.org,  tglx@linutronix.de, tmgross@umich.edu
Subject: Re: [PATCH v1 1/2] rust: time: Rename Delta's methods as_micros_ceil and as_millis
Date: Thu, 19 Jun 2025 09:23:38 +0200	[thread overview]
Message-ID: <CANiq72kacWaLo=EE8WyA_M2Pr9h1MkqjeAmqet6CSGWLvM7B9g@mail.gmail.com> (raw)
In-Reply-To: <20250619.160844.1477802332578239775.fujita.tomonori@gmail.com>

On Thu, Jun 19, 2025 at 9:08 AM FUJITA Tomonori
<fujita.tomonori@gmail.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

  reply	other threads:[~2025-06-19  7:23 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-06-17 14:41 [PATCH v1 0/2] rust: time: Add fsleep() FUJITA Tomonori
2025-06-17 14:41 ` [PATCH v1 1/2] rust: time: Rename Delta's methods as_micros_ceil and as_millis FUJITA Tomonori
2025-06-18  8:05   ` Alice Ryhl
2025-06-18  9:29     ` Miguel Ojeda
2025-06-18  9:52       ` Alice Ryhl
2025-06-18 11:03         ` Miguel Ojeda
2025-06-18 13:17           ` Alice Ryhl
2025-06-18 15:47             ` Miguel Ojeda
2025-06-19  7:08               ` FUJITA Tomonori
2025-06-19  7:23                 ` Miguel Ojeda [this message]
2025-06-19  9:28                   ` Andreas Hindborg
2025-06-19 11:44                     ` Miguel Ojeda
2025-06-19 12:51                       ` Andreas Hindborg
2025-06-19 19:03                         ` Miguel Ojeda
2025-06-24 12:15                 ` Alice Ryhl
2025-06-24 13:49                   ` FUJITA Tomonori
2025-06-24 13:54                     ` Alice Ryhl
2025-06-24 14:14                       ` FUJITA Tomonori
2025-06-24 14:45                         ` Alice Ryhl
2025-06-24 16:39                           ` FUJITA Tomonori
2025-06-19  9:12   ` Andreas Hindborg
2025-06-19 11:25     ` FUJITA Tomonori
2025-06-17 14:41 ` [PATCH v1 2/2] rust: time: Add wrapper for fsleep() function FUJITA Tomonori
2025-06-30 12:07   ` Andreas Hindborg

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CANiq72kacWaLo=EE8WyA_M2Pr9h1MkqjeAmqet6CSGWLvM7B9g@mail.gmail.com' \
    --to=miguel.ojeda.sandonis@gmail.com \
    --cc=a.hindborg@kernel.org \
    --cc=alex.gaynor@gmail.com \
    --cc=aliceryhl@google.com \
    --cc=anna-maria@linutronix.de \
    --cc=bjorn3_gh@protonmail.com \
    --cc=boqun.feng@gmail.com \
    --cc=dakr@kernel.org \
    --cc=frederic@kernel.org \
    --cc=fujita.tomonori@gmail.com \
    --cc=gary@garyguo.net \
    --cc=jstultz@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lossin@kernel.org \
    --cc=lyude@redhat.com \
    --cc=ojeda@kernel.org \
    --cc=rust-for-linux@vger.kernel.org \
    --cc=sboyd@kernel.org \
    --cc=tglx@linutronix.de \
    --cc=tmgross@umich.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).