From: "gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>
To: Timur Tabi <ttabi@nvidia.com>
Cc: "ojeda@kernel.org" <ojeda@kernel.org>,
"dakr@kernel.org" <dakr@kernel.org>,
"aliceryhl@google.com" <aliceryhl@google.com>,
"miguel.ojeda.sandonis@gmail.com"
<miguel.ojeda.sandonis@gmail.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: Thu, 5 Jun 2025 17:21:04 +0200 [thread overview]
Message-ID: <2025060511-surcharge-overfill-a721@gregkh> (raw)
In-Reply-To: <7faac30f75f2ba651995d9667c463706b61ffca5.camel@nvidia.com>
On Thu, Jun 05, 2025 at 03:02:03PM +0000, Timur Tabi wrote:
> On Thu, 2025-06-05 at 08:07 +0200, Greg KH wrote:
> > > Maybe dbs!(), or just d!() ?
> >
> > Wait, why are we trying to reimplement the existing pr_dbg() code in a
> > non-standard-way?
>
> pr_dbg() is not changing. We're talking about the standard Rust macro dbg!()
>
> https://doc.rust-lang.org/std/macro.dbg.html
>
> the "problem" with dbg! is that it uses file!(), which outputs the full relative path of the
> source file, which can be quite lengthy. IOW, I think dbg!() is often too noisy.
And I'm saying "don't use dbg!()" :)
Or, better yet, have it do exactly what pr_dbg() does, as we don't seem
to _have_ to have dbg!() follow anything other than whatever we want it
to follow.
> And we're not talking about changing dbg!() either. In cases where a given Rust driver has
> multiple source files of the same name but in different paths, you probably want dbg!() to use
> file!().
Again, just do what pr_dbg() does, nothing more and nothing less.
> But in situations where you don't have that file layout, maybe you would prefer the output of my
> sfile!() macro.
Nope, use what pr_dbg() does please. It will provide the needed file
info if the user asks for it through the standard user/kernel api that
we all know and "love".
thanks,
greg k-h
next prev parent reply other threads:[~2025-06-05 15:21 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
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 [this message]
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=2025060511-surcharge-overfill-a721@gregkh \
--to=gregkh@linuxfoundation.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