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