KTR_SPAREx

[John Baldwin]

On Tuesday, June 05, 2012 8:25:33 am Dag-Erling Smørgrav wrote:
> Most of this is in device drivers, which should use KTR_DEV.  There is
> one major use of KTR_SPAREx in common code: KTR_SPARE2 is used for clock
> events.  It is also used incorrectly by the sparc64 pmap core (there is
> a separate KTR_PMAP for that).
> 
> I suggest that we
> 
> 1) rename one of the spare KTRs to KTR_CLOCK and use that for clock
>    events.  I already have a patch for that.
> 
> 2) eliminate all other use of KTR_SPARE[0-9] in non-device code.  I
>    think the existing KTRs should already cover most cases.
> 
> 3) modify device drivers to use KTR_DEV for events that aren't covered
>    by existing, more specific KTRs, which is almost none.  For instance,
>    there is no reason why cxgb shouldn't just use KTR_NET.

There is a reason in that you may want to only get those specific events and
not drown in noise from the network stack itself for example.  What I tend to
do in drivers where I want to do this is have something like this:

#if 0
#define KTR_CXGB KTR_DEV
#else
#define KTR_CXGB 0
#endif

and then use 'KTR_CXGB' instead of 'KTR_DEV' or 'KTR_SPARE2' explicitly.  It 
looks like most of the drivers are already doing this and if it is #if 0'd by
default, then I would just let them be.  The two CTR()s in tom/cxgb_cpl_io.c
should probably be using KTR_TOM instead of KTR_SPARE2 directly.

As a long term goal I would like to switch to using individual ints instead of 
a 32-bit bitmask as that would let us add new trace classes with ease.  I 
haven't figured out a design for that that I fully like yet however.

-- 
John Baldwin