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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.