Re: [PATCH 4/6] mac80211: clean up debugging

[Jason Baron <jbaron@redhat.com>]

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
>