[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <c56c82d2455f4183a51cd414edc0a9b1@SIXPR30MB031.064d.mgd.msft.net>
Date: Mon, 20 Jul 2015 05:30:50 +0000
From: Dexuan Cui <decui@...rosoft.com>
To: Vitaly Kuznetsov <vkuznets@...hat.com>
CC: David Miller <davem@...emloft.net>,
"olaf@...fle.de" <olaf@...fle.de>,
"gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
"jasowang@...hat.com" <jasowang@...hat.com>,
"driverdev-devel@...uxdriverproject.org"
<driverdev-devel@...uxdriverproject.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"stephen@...workplumber.org" <stephen@...workplumber.org>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"apw@...onical.com" <apw@...onical.com>,
"pebolle@...cali.nl" <pebolle@...cali.nl>
Subject: RE: [V2 6/7] hvsock: introduce Hyper-V VM Sockets feature
> -----Original Message-----
> From: Vitaly Kuznetsov
> Sent: Friday, July 17, 2015 23:04
> To: Dexuan Cui
> Dexuan Cui writes:
>
> >> From: David Miller
> >> Sent: Thursday, July 16, 2015 12:19
> >>
> >> From: Dexuan Cui
> >> Date: Tue, 14 Jul 2015 03:00:48 -0700
> >>
> >> > + pr_debug("hvsock_sk_destruct: called\n");
> >>
> >> Debug logging just to state that a function is called is not appropriate,
> >> we have very sophisticated tracing facilities in the kernel that can do
> >> that transparently, and more.
> >>
> >> Please remove this.
> > OK.
> >
> >> > + if (hvsk->channel) {
> >> > + pr_debug("hvsock_sk_destruct: calling vmbus_close()\n");
> >>
> >> Likewise, these kinds of debug logs are totally inappropriate.
> > OK, I'll remove all the pr_debug() in the patch.
> >
>
> I'd suggest we rather use something like net_dbg_ratelimited()
> intead. The driver is new so issues are expected. Some debugging may
> be useful)
>
> Vitaly
The net_*ratelimited() functions may lose message if the messages are
printed very frequently, like in hvsock_sendmsg()/hvsock_recvmsg().
I used pr_debug() because I saw it's widely used in net/ipv4/.
Usually CONFIG_DYNAMIC_DEBUG=y, so pr_debug() means
dynamic_pr_debug(), which won't output anything by default.
Sorry, I'm not sure about the "sophisticated tracing facilities in the
kernel that can do that transparently, and more" mentioned by David.
Anyway, I don't mind simply removing the pr_debug() usages.
I will send out V3 later today.
Thanks,
-- Dexuan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists