KTR_SPAREx

[Dag-Erling Smørgrav]

Konstantin Belousov <kostikbel at gmail.com> writes:
> Dag-Erling Smørgrav <des at des.no> writes:
>> We only have a limited number of KTR types - 32, to be precise.  We
>> can't spare one for each driver, and there's no reason why *your* driver
>> (for any value of "you") should get its own while everybody else shares
>> KTR_DEV.
> I want to have only *my* driver trace points in the ring, by whatever
> means. Breaking it right now would mean that I cannot do any GEM
> debugging.

Well, so does everybody else.  Here is a list of files that use the same
KTR that you use for GEM (KTR_SPARE2):

sys/kern/kern_clocksource.c
sys/amd64/amd64/machdep.c
sys/dev/cxgb/cxgb_osdep.h
sys/dev/cxgb/ulp/tom/cxgb_defs.h
sys/dev/cxgb/ulp/tom/cxgb_cpl_io.c
sys/dev/gem/if_gem.c
sys/dev/hme/if_hme.c
sys/dev/cas/if_cas.c
sys/i386/xen/xen_machdep.c
sys/i386/i386/machdep.c
sys/powerpc/powerpc/cpu.c
sys/pc98/pc98/machdep.c
sys/sparc64/sparc64/pmap.c
sys/sparc64/sparc64/tsb.c
sys/sparc64/include/bus.h

Note that sys/*/*/machdep.c issue a KTR_SPARE2 event every time the CPU
enters or exits the idle thread.

> > If you think KTR_DEV is too noisy, add sysctls to enable or disable
> > tracing on a per-device basis.  It should be quite easy to generalize.
> So you are planning to break some useful, but possibly randomly-achieved
> functionality, and delegate the work to repair it to somebody else ?

It's already broken, and you're one of the people responsible for
breaking it.  I'm trying to fix it.

DES
-- 
Dag-Erling Smørgrav - des at des.no