From: Jason Gunthorpe <jgg@nvidia.com>
To: Zhu Yanjun <yanjun.zhu@linux.dev>
Cc: Zhu Yanjun <yanjun.zhu@intel.com>,
zyjzyj2000@gmail.com, leon@kernel.org,
linux-rdma@vger.kernel.org
Subject: Re: [PATCH 1/1] RDMA/rxe: Add function name to the logs
Date: Fri, 28 Apr 2023 10:24:22 -0300 [thread overview]
Message-ID: <ZEvJBk70YPvO1QDI@nvidia.com> (raw)
In-Reply-To: <1fbd5b6f-ba04-95b3-d37c-35fc12e81303@linux.dev>
On Fri, Apr 21, 2023 at 11:51:34PM +0800, Zhu Yanjun wrote:
>
> 在 2023/4/21 23:27, Jason Gunthorpe 写道:
> > On Tue, Apr 18, 2023 at 08:26:11PM +0800, Zhu Yanjun wrote:
> > > From: Zhu Yanjun <yanjun.zhu@linux.dev>
> > >
> > > Add the function names to the pr_ logs. As such, if some bugs occur,
> > > with function names, it is easy to locate the bugs.
> > >
> > > Signed-off-by: Zhu Yanjun <yanjun.zhu@linux.dev>
> > > ---
> > > drivers/infiniband/sw/rxe/rxe.h | 2 +-
> > > drivers/infiniband/sw/rxe/rxe_queue.h | 16 ++++------------
> > > 2 files changed, 5 insertions(+), 13 deletions(-)
> > After you delete the warn_on's there is very little left:
> >
> > rivers/infiniband/sw/rxe/rxe.c: pr_err("rxe creation allowed on top of a real device only\n");
> > drivers/infiniband/sw/rxe/rxe.c: pr_info("loaded\n");
> > drivers/infiniband/sw/rxe/rxe.c: pr_info("unloaded\n");
> > drivers/infiniband/sw/rxe/rxe_net.c: pr_err("Failed to create IPv4 UDP tunnel\n");
> > drivers/infiniband/sw/rxe/rxe_net.c: pr_warn("IPv6 is not supported, can not create a UDPv6 socket\n");
> > drivers/infiniband/sw/rxe/rxe_net.c: pr_err("Failed to create IPv6 UDP tunnel\n");
> > drivers/infiniband/sw/rxe/rxe_net.c: pr_err("Failed to register netdev notifier\n");
> >
> > It is not exactly mysterious where these come from?
>
> If I got you correctly, you mean that we can easily locate the above pr_xxx
> logs. As such, it is not necessary to add function names.
>
> From this perspective, I agree with you.
>
> Why I make this commit is that we can directly use this pr_info("xxxxx")
> when some bug occurs. But in the logs, the function names appear.
>
> With this commit, we can decrease some work loads with some bug occurs.
That doesn't seem like a good reason to merge something so abnormal
for pr_* functions
Jason
next prev parent reply other threads:[~2023-04-28 13:24 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-18 12:26 [PATCH 1/1] RDMA/rxe: Add function name to the logs Zhu Yanjun
2023-04-21 15:27 ` Jason Gunthorpe
2023-04-21 15:51 ` Zhu Yanjun
2023-04-28 13:24 ` Jason Gunthorpe [this message]
-- strict thread matches above, loose matches on Subject: below --
2023-04-10 10:21 Zhu Yanjun
2023-04-16 14:43 ` Zhu Yanjun
2023-04-18 8:08 ` Leon Romanovsky
2023-04-18 10:36 ` Zhu Yanjun
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=ZEvJBk70YPvO1QDI@nvidia.com \
--to=jgg@nvidia.com \
--cc=leon@kernel.org \
--cc=linux-rdma@vger.kernel.org \
--cc=yanjun.zhu@intel.com \
--cc=yanjun.zhu@linux.dev \
--cc=zyjzyj2000@gmail.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