From: "Benno Lossin" <lossin@kernel.org>
To: "Miguel Ojeda" <miguel.ojeda.sandonis@gmail.com>,
"Timur Tabi" <ttabi@nvidia.com>
Cc: "ojeda@kernel.org" <ojeda@kernel.org>,
"dakr@kernel.org" <dakr@kernel.org>,
"aliceryhl@google.com" <aliceryhl@google.com>,
"rust-for-linux@vger.kernel.org" <rust-for-linux@vger.kernel.org>
Subject: Re: [PATCH] rust: introduce sfile macro for easier code tracing
Date: Wed, 04 Jun 2025 17:16:54 +0200 [thread overview]
Message-ID: <DADUK09NUMP6.3Q5UVROS0QDYF@kernel.org> (raw)
In-Reply-To: <CANiq72mLEFV6iEX43=+d+5P8g9HT+Wip7eTBgPgqXQ--=dQxWQ@mail.gmail.com>
On Wed Jun 4, 2025 at 12:28 PM CEST, Miguel Ojeda wrote:
> On Wed, Jun 4, 2025 at 1:29 AM Timur Tabi <ttabi@nvidia.com> wrote:
>>
>> I didn't want to change the existing behavior of any other macro or function. This is my first
>> significant rust-for-linux contribution, and I didn't want to be presumptuous.
>
> No worries -- things can be changed, and in particular the behavior of
> `dbg!` wouldn't be too bad, in the sense that calls are not meant to
> be committed anyway. A CI checking for the message from the sample
> could break I guess, but that is not the end of the world.
>
>> I could add a sdbg!() if you think it would be useful.
>
> Yeah, that was what I was thinking, though it is sadly one more letter.
>
> We could also shorten a bit more by not printing the column like
> `dbg!` does, which I suspect many may not care about.
>
> I wonder if we could make the `dbg!` the one with the longer name
> instead, i.e. to keep the functionality in case someone really needs
> it. Sadly, that means making it not match the stdlib name, but it may
> be worth it if we expect everyone to end up typing `sdbg!` all the
> time, and only very rarely `dbg!`.
Why not control the amount of path segments with a kconfig? That way we
can have both worlds.
---
Cheers,
Benno
next prev parent reply other threads:[~2025-06-04 15:16 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-29 18:45 [PATCH] rust: introduce sfile macro for easier code tracing Timur Tabi
2025-05-29 20:14 ` Benno Lossin
2025-06-03 17:15 ` Timur Tabi
2025-06-03 21:54 ` Benno Lossin
2025-05-29 20:21 ` Miguel Ojeda
2025-06-03 18:15 ` Timur Tabi
2025-06-03 21:58 ` Benno Lossin
2025-06-03 22:05 ` Timur Tabi
2025-06-03 22:15 ` Miguel Ojeda
2025-06-04 23:12 ` Timur Tabi
2025-06-05 3:20 ` Miguel Ojeda
2025-06-03 22:15 ` Miguel Ojeda
2025-06-03 23:29 ` Timur Tabi
2025-06-04 10:28 ` Miguel Ojeda
2025-06-04 15:16 ` Benno Lossin [this message]
2025-06-04 15:41 ` Miguel Ojeda
2025-06-05 6:05 ` Greg KH
2025-06-04 20:38 ` Timur Tabi
2025-06-05 6:07 ` Greg KH
2025-06-05 15:02 ` Timur Tabi
2025-06-05 15:21 ` gregkh
2025-06-05 15:38 ` Miguel Ojeda
2025-06-05 16:42 ` gregkh
2025-06-05 17:39 ` Miguel Ojeda
2025-06-06 15:50 ` Miguel Ojeda
2025-05-30 3:47 ` kernel test robot
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=DADUK09NUMP6.3Q5UVROS0QDYF@kernel.org \
--to=lossin@kernel.org \
--cc=aliceryhl@google.com \
--cc=dakr@kernel.org \
--cc=miguel.ojeda.sandonis@gmail.com \
--cc=ojeda@kernel.org \
--cc=rust-for-linux@vger.kernel.org \
--cc=ttabi@nvidia.com \
/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).