Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 5 Jun 2012 16:20:00 +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-FndAadYbqiWUTupXLEcRMkYYL50Ssehi8f8vv6YXvQzy4OA@mail.gmail.com>
In-Reply-To: <CAJ-FndAMsoB1RAyS-Pa1JCv7W0qsviRxtShZ3uk_Tpd%2BJ_EBaQ@mail.gmail.com>
References:  <86bokyvtc2.fsf@ds4.des.no> <CAJ-FndAMsoB1RAyS-Pa1JCv7W0qsviRxtShZ3uk_Tpd%2BJ_EBaQ@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
2012/6/5 Attilio Rao <attilio@freebsd.org>:
> 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=A0Her=
e 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


--=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-FndAadYbqiWUTupXLEcRMkYYL50Ssehi8f8vv6YXvQzy4OA>