From owner-freebsd-arch@FreeBSD.ORG Tue Jun 5 15:02:17 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0BDD41065670 for ; Tue, 5 Jun 2012 15:02:17 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id D142E8FC16 for ; Tue, 5 Jun 2012 15:02:16 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 441E1B95D; Tue, 5 Jun 2012 11:02:16 -0400 (EDT) From: John Baldwin To: freebsd-arch@freebsd.org Date: Tue, 5 Jun 2012 09:47:48 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p13; KDE/4.5.5; amd64; ; ) References: <86bokyvtc2.fsf@ds4.des.no> In-Reply-To: <86bokyvtc2.fsf@ds4.des.no> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <201206050947.48750.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 05 Jun 2012 11:02:16 -0400 (EDT) Cc: Dag-Erling =?utf-8?q?Sm=C3=B8rgrav?= Subject: Re: KTR_SPAREx X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jun 2012 15:02:17 -0000 On Tuesday, June 05, 2012 8:25:33 am Dag-Erling Sm=C3=B8rgrav wrote: > Most of this is in device drivers, which should use KTR_DEV. There is > one major use of KTR_SPAREx in common code: KTR_SPARE2 is used for clock > events. It is also used incorrectly by the sparc64 pmap core (there is > a separate KTR_PMAP for that). >=20 > I suggest that we >=20 > 1) rename one of the spare KTRs to KTR_CLOCK and use that for clock > events. I already have a patch for that. >=20 > 2) eliminate all other use of KTR_SPARE[0-9] in non-device code. I > think the existing KTRs should already cover most cases. >=20 > 3) modify device drivers to use KTR_DEV for events that aren't covered > by existing, more specific KTRs, which is almost none. For instance, > there is no reason why cxgb shouldn't just use KTR_NET. There is a reason in that you may want to only get those specific events and not drown in noise from the network stack itself for example. What I tend = to do in drivers where I want to do this is have something like this: #if 0 #define KTR_CXGB KTR_DEV #else #define KTR_CXGB 0 #endif and then use 'KTR_CXGB' instead of 'KTR_DEV' or 'KTR_SPARE2' explicitly. I= t=20 looks like most of the drivers are already doing this and if it is #if 0'd = by default, then I would just let them be. The two CTR()s in tom/cxgb_cpl_io.c should probably be using KTR_TOM instead of KTR_SPARE2 directly. As a long term goal I would like to switch to using individual ints instead= of=20 a 32-bit bitmask as that would let us add new trace classes with ease. I=20 haven't figured out a design for that that I fully like yet however. =2D-=20 John Baldwin