Date: Tue, 5 Jun 2012 16:18:53 +0100 From: Attilio Rao <attilio@freebsd.org> To: =?UTF-8?Q?Dag=2DErling_Sm=C3=B8rgrav?= <des@des.no> Cc: arch@freebsd.org Subject: Re: KTR_SPAREx Message-ID: <CAJ-FndAMsoB1RAyS-Pa1JCv7W0qsviRxtShZ3uk_Tpd%2BJ_EBaQ@mail.gmail.com> In-Reply-To: <86bokyvtc2.fsf@ds4.des.no> References: <86bokyvtc2.fsf@ds4.des.no>
next in thread | previous in thread | raw e-mail | index | archive | help
2012/6/5 Dag-Erling Sm=C3=B8rgrav <des@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. =C2=A0KTR_SPARE[234] are all documented as "/* XXX Used by cxgb */"= , > but KTR_SPARE3, for instance, is widely used for clock events. =C2=A0Here= 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. Attilio --=20 Peace can only be achieved by understanding - A. Einstein
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-FndAMsoB1RAyS-Pa1JCv7W0qsviRxtShZ3uk_Tpd%2BJ_EBaQ>