KTR_SPAREx

Attilio Rao attilio at freebsd.org
Tue Jun 5 15:20:02 UTC 2012


2012/6/5 Attilio Rao <attilio at freebsd.org>:
> 2012/6/5 Dag-Erling Smørgrav <des at des.no>:
>> While working on Capsicum last year, I noticed that some of the spare
>> KTR types are (ab)used for different purposes by different parts of the
>> code.  KTR_SPARE[234] are all documented as "/* XXX Used by cxgb */",
>> but KTR_SPARE3, for instance, is widely used for clock events.  Here is
>> a complete list:
>
> The truth is, KTR is thought to be a mechanism for catering
> "on-the-fly" the tracing of the events, but the very limited
> mask/classes of events it provides makes this completely useless.
> I don't recall a case where I had to not patch manually KTR knobs to
> do actual debugging.
>
> What I really would like to see is:
> - Of course remove the bogus usage of KTR_SPAREX in the drivers
> - Make the mask of events much bigger than the current one
> - Enlarge the number of KTR_SPARE available (16 would be ok)
> - By default have KTR_SPARE0-15 to be on in the kernel along with KTR
> option, or maybe when the kernel is still in the debugging phase (but
> leave in a knob for disabling it)
> - Use the dynamic masking system to just mask the SPARE you are
> interested into. This way your driver can simply use a KTR_SPARE for
> development and you will mask out the right one at run time.

Forgot to mention, even if this is mostly unrelated to your point: we
should make a better job of breaking further the current set of KTR
classes on a per-subsystem basis. KTR_VFS or KTR_VM (and others) are
far too large right now.

Attilio


-- 
Peace can only be achieved by understanding - A. Einstein


More information about the freebsd-arch mailing list