From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from mx1.redhat.com ([209.132.183.28]:1025 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755965Ab2FYV3K (ORCPT ); Mon, 25 Jun 2012 17:29:10 -0400 Date: Mon, 25 Jun 2012 17:29:04 -0400 From: Jason Baron To: Johannes Berg Cc: Joe Perches , linux-wireless@vger.kernel.org, Jim Cromie Subject: Re: [PATCH 4/6] mac80211: clean up debugging Message-ID: <20120625212904.GA9245@redhat.com> (sfid-20120625_232913_928970_2ADBE5C1) References: <1340385525-14487-1-git-send-email-johannes@sipsolutions.net> <1340385525-14487-5-git-send-email-johannes@sipsolutions.net> <1340438536.2274.9.camel@joe2Laptop> <1340456697.4636.1.camel@jlt3.sipsolutions.net> <1340466044.7758.4.camel@joe2Laptop> <1340530258.4577.4.camel@jlt3.sipsolutions.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: <1340530258.4577.4.camel@jlt3.sipsolutions.net> Sender: linux-wireless-owner@vger.kernel.org List-ID: On Sun, Jun 24, 2012 at 11:30:58AM +0200, Johannes Berg wrote: > On Sat, 2012-06-23 at 08:40 -0700, Joe Perches wrote: > > > > FWIW, I would definitely prefer named rather than bitmap selectors :-) > > > > (Added Jason and Jim) > > > > Given it's a debug-only facility, I think bitmap > > selectors sufficient, Maybe adding an external > > utility to map names to bits would be enough to > > not need that feature in the kernel. > I've been thinking about that too - given that we can control each individual statement from userspace, perhaps most of the implementation for level/bitmap support could and should be done in userspace. For levels, we add 1 additional field to the pr_debug() statement, and its easy enough to construct a command-line to turn on the correct statements. For flags it should be just as easy but we probably want to export a table mapping kernel strings to to bitmask fields as well. So some simple wrapper scripts would probably make this pretty easy. > I guess the real question isn't whether it should be a bitmap or a name > or whatever, it's how it's implemented. To allay fears about runtime > overhead, I think it would be good to use the jump_label mechanism to > implement it -- I do realise that still has runtime overhead for the > argument preparation, but still. > > Looking at the history, it seems that jump labels were at one point used > by reverted to fix gcc 3.3, I'm sure that could be resolved? Yes, there were some circular header dependencies issues - but they can be resolved. I will re-post this work. > > Anyway, the point is that if it uses jump labels then we need some sort > of house-keeping structures anyway to be able to enable/disable the > right jump labels. And that could easily have a string attached, which > would make it easier when working with bug reporters etc. since you > don't have to worry about the exact bitmap, you can give them a string > (and if it's wrong, there will be a failure rather than silently getting > the wrong data) > > johannes >