From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755099AbbDUOfL (ORCPT ); Tue, 21 Apr 2015 10:35:11 -0400 Received: from casper.infradead.org ([85.118.1.10]:45506 "EHLO casper.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752744AbbDUOfH (ORCPT ); Tue, 21 Apr 2015 10:35:07 -0400 Date: Tue, 21 Apr 2015 11:35:01 -0300 From: Arnaldo Carvalho de Melo To: Steven Rostedt Cc: David Ahern , Namhyung Kim , LKML Subject: Re: perf/tracepoints access to interpreted strings Message-ID: <20150421143501.GA11111@kernel.org> References: <552E8FB8.6010005@gmail.com> <20150415180927.GR16027@kernel.org> <20150420164616.4227fae9@gandalf.local.home> <20150420212535.GS11111@kernel.org> <55356F20.2090706@gmail.com> <20150421090733.3a6cc742@gandalf.local.home> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150421090733.3a6cc742@gandalf.local.home> X-Url: http://acmel.wordpress.com User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Em Tue, Apr 21, 2015 at 09:07:33AM -0400, Steven Rostedt escreveu: > On Mon, 20 Apr 2015 15:26:56 -0600 David Ahern wrote: > > On 4/20/15 3:25 PM, Arnaldo Carvalho de Melo wrote: > > > Em Mon, Apr 20, 2015 at 04:46:16PM -0400, Steven Rostedt escreveu: > > >> On Wed, 15 Apr 2015 15:09:27 -0300 Arnaldo Carvalho de Melo wrote: > > >> Note, with the new TRACE_DEFINE_ENUM() that was already added to > > >> Linus's tree, that print_fmt now looks like: > > >> print fmt: "vec=%u [action=%s]", REC->vec, __print_symbolic(REC->vec, > > >> { 0, "HI" }, { 1, "TIMER" }, { 2, "NET_TX" }, { 3, "NET_RX" }, { 4, "BLOCK" }, > > >> { 5, "BLOCK_IOPOLL" }, { 6, "TASKLET" }, { 7, "SCHED" }, { 8, "HRTIMER" }, > > >> { 9, "RCU" }) > > > That is better, indeed, covers holes :-) > > Seems to me that means 2 different implementations are needed ... old > > and new. > Why? The above is the way most trace points use __print_symbolic(). I think he is talking about any user space implementation handling those enum->STR mappings, __print_symbolic() included. > It's just when a tracepoint uses enums instead of defines or hard coded > numbers do the useless enum name pops up. > Any parse should be expecting numbers, not enum names. Humm, I found that the point was that on field 'vec' we receive a number, and we want to format it to something less cryptic, so we need to map a number to a string. The original implementation, that doesn't have that { number, string } will fail to handle sparse enums, because we can't map number -> "string". So it has to handle both: 1) { string, "string" } 2) { number, "string" } And for 1) keep some blacklist of { tracepoint, field-list } that can't be safely mapped number -> "string", i.e. a blacklist of sparse enums, no? David, we could as well just blacklist all kernels where 1) is used and do no mapping, supporting only 2) kernels. We can do that by parsing the first element, and if it is not a number, blacklist it. - Arnaldo