Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757549AbZA2Nje (ORCPT ); Thu, 29 Jan 2009 08:39:34 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751644AbZA2NjZ (ORCPT ); Thu, 29 Jan 2009 08:39:25 -0500 Received: from mail-fx0-f26.google.com ([209.85.220.26]:45443 "EHLO mail-fx0-f26.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751289AbZA2NjY (ORCPT ); Thu, 29 Jan 2009 08:39:24 -0500 DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=LlGFn2kRRA95P6/pcCnMf+EjpavWjHeKQl16cqjBoG1Ru8Hv6nsxBGsWbN5evNmJFh yh8Ivlb5chqYaEGGNVUtdPQ1MWv0tcLvYfkNyRpqA9aogX1d9SMYRlbQug0fpk1WGwtm EnHweCwU0zGMdl0DyBvhCrJJCTo/dbYAhOLxo= MIME-Version: 1.0 In-Reply-To: <20090129004510.GH627@ghostprotocols.net> References: <497F69A4.2070007@intel.com> <20090127205137.GD15877@ghostprotocols.net> <20090127211452.GA5850@nowhere> <4980D6A0.9030004@intel.com> <20090129004510.GH627@ghostprotocols.net> Date: Thu, 29 Jan 2009 14:39:21 +0100 Message-ID: Subject: Re: [PATCH] tracer for sys_open() - sreadahead From: =?ISO-8859-1?Q?Fr=E9d=E9ric_Weisbecker?= To: Arnaldo Carvalho de Melo , "Kok, Auke" , Frederic Weisbecker , Linux Kernel Mailing List , powertop ml , Arjan van de Ven , Ingo Molnar , "srostedt@redhat.com" , "Frank Ch. Eigler" , Neil Horman , "Kok, Auke" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2408 Lines: 67 2009/1/29 Arnaldo Carvalho de Melo : > hey, hey, your patch just illustrated that we need a subtype facility. > > I'm (as all the other people in some shape or form involved in pushing > some sort of common tracing infrastructure into the kernel, I guess) > excited about more developers using what is being put in place :-) Indeed :-) About these subtypes. I've thought about what can be intuitive for developers who will use it. I think the struct trace_event can be reused by just adding a subtype event inside: + int (*find_subtype_func) (struct trace_iterator *); struct trace_event { struct hlist_node node; int type; trace_print_func trace; trace_print_func latency_trace; trace_print_func raw; trace_print_func hex; trace_print_func binary; + struct trace_event *subevent_array; + find_subtype_func find_subtype; }; And then I shall implement an event internal hlist for each global event. All a tracer developer just have to do is: _ implement a general trace_event for his global event type _ implement each trace subevent as an array, one will have to define its own set of values for the types, they will not conflict with those used by global event types since they are isolated and depend on one global event type. _ implement find_subtype callback. When a new trace has to be printed, this callback is called to find the subtype value corresponding to a trace. If the tracer returns a positive value, the matching subevent is searched on the subevent_array and the appropriate trace_print_func is called. Otherwise if find_subtype is NULL or returns -EINVAL, then the appropriate trace_print_func of the current global event is called, as usual. We can even make it recursive, letting one crazy tracer beeing able to have subtypes of subtypes :-) Hm? If you are ok, I shall start it. >> In all it was not productive to write a giant trace facility just to get >> sreadahead one tracer type. Now that the code works and the benefit is proven, I'm >> happy to see if we can work on making a decent long-term non-specialistic solution. > > That is the spirit! > > - Arnaldo > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/