From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from s3.sipsolutions.net ([5.9.151.49]:33582 "EHLO sipsolutions.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753370AbbLKOiw (ORCPT ); Fri, 11 Dec 2015 09:38:52 -0500 Message-ID: <1449844729.2324.15.camel@sipsolutions.net> (sfid-20151211_153914_020978_EF6C48F5) Subject: Re: [PATCH] wireless: change cfg80211 regulatory domain info as debug messages From: Johannes Berg To: Dave Young , linux-wireless@vger.kernel.org Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org, davem@davemloft.net, Emmanuel Grumbach , Stefan Lippers-Hollmann Date: Fri, 11 Dec 2015 15:38:49 +0100 In-Reply-To: <20151115073105.GA18846@dhcp-128-65.nay.redhat.com> References: <20151115073105.GA18846@dhcp-128-65.nay.redhat.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Sender: linux-wireless-owner@vger.kernel.org List-ID: On Sun, 2015-11-15 at 15:31 +0800, Dave Young wrote: > cfg80211 module prints a lot of messages like below. Actually > printing once is acceptable but sometimes it will print again and > again, it looks very annoying. It is better to change these detail > messages to debugging only. > Despite the objections, I've applied this patch now. I've made one change: keeping the alpha2 (e.g. "US") printed in some of the pr_err() cases in this file. I also got rid of CONFIG_CFG80211_REG_DEBUG in a separate patch. I somewhat agree with the objections, but if the kernel is with CONFIG_DYNAMIC_DEBUG then it's really simple to get the messages back by enabling them for this file. Where the messages were used as an indication of something having gone awry at a different level (e.g. mac80211 disconnect) I don't really quite agree - that then perhaps should have a more explicit (and less noisy) message. I also agree that the regulatory code is quite opaque, and the way it arrives at certain conclusions is not always obvious. These messages don't help all that much though since they don't contain the actual input to the decisions. I think for that, we'd be much better served with some kind of tracepoint or so that records all the information. johannes