From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S966005AbbDVQfq (ORCPT ); Wed, 22 Apr 2015 12:35:46 -0400 Received: from mail03v-smtp01.fnal.gov ([131.225.199.28]:58165 "EHLO ex-smtp.fnal.gov" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S965235AbbDVQfn (ORCPT ); Wed, 22 Apr 2015 12:35:43 -0400 Message-ID: <5537CDDD.2080903@fnal.gov> Date: Wed, 22 Apr 2015 11:35:41 -0500 From: Ron Rechenmacher Reply-To: User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Steven Rostedt CC: David Ahern , Arnaldo Carvalho de Melo , Christoph Hellwig , , Arjan van de Ven , Namhyung Kim , Pawel Moll , "Stephane Eranian" Subject: Re: [PATCH] tracing: Export key trace event symbols References: <55364CF4.2090600@fnal.gov> <20150421132355.GA18161@infradead.org> <55365002.4010707@fnal.gov> <20150421095310.12370f88@gandalf.local.home> <55366609.4020709@fnal.gov> <20150421114931.63fd343d@gandalf.local.home> <5536CDF1.2020801@fnal.gov> <20150421184446.7b63cbec@gandalf.local.home> <55370673.60504@fnal.gov> <20150422085314.1b07e0b7@gandalf.local.home> <20150422144751.GC2316@kernel.org> <5537BFF4.1050605@gmail.com> <20150422114451.298d8184@gandalf.local.home> In-Reply-To: <20150422114451.298d8184@gandalf.local.home> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [131.225.86.197] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Thanks, Steve :) I was working on a reply to your previous email but I'll reply here. I'm happy with how this is going and I'm really appreciative of how you have/are handling (managing) this. Thanks! Assuming I'm only getting the tip of the ice berg of "normal Linux kernel development," I don't know if it's reasonable to achieve a balance between discussing "accepting the patch" and "what I'm doing with TRACE." If I may, I can separate the two as follows (and focusing more on "accepting the patch"): In my 30 year evolution of TRACE, a significant point came (somewhere in the 1990's) when, with Vxworks, I noticed that they had a "task switch hook add" routine and I was able to incorporate kernel task switching events in with the application traces. My first patches to the linux-2.2 kernel included a patch to the scheduler and interrupts came quickly there after. I was always wondering if Linux would one day provide "task switch hook" capability. In early 2013, when I started the v3 of TRACE, I was extremely happy to find the symbol "register_trace_sched_switch" --- this was all I needed and I thought "they did it." With the understanding, as has been mentioned before, that "only the user space ABI is what we keep stable" and that before commit de7b2973903c (tracepoint: Use struct pointer instead of name hash for reg/unreg tracepoints) it was just "lucky" that I could use the register_tracepoint_* routines as somewhat generic "add hook" routines (from external modules), is it now reasonable to accept my patch to allow external modules to "add hooks" to key events in Linux? Why or why not? Thanks, Ron Steven Rostedt wrote on 04/22/15 10:44: > On Wed, 22 Apr 2015 09:36:20 -0600 > David Ahern wrote: > >> One of the key requirements is a common time basis (e.g., >> CLOCK_MONOTONIC or PERF_CLOCK) to be able to merge the events properly. >> I have a kernel module that exports perf_clock to userspace via >> clock_gettime; the 4.1 kernel should have the code that allows the clock >> id to be specified providing a solution to this problem. > > Ron, > > I should have warned you. This is normal Linux kernel development. > Someone posts a simple patch to make something of there's work better, > and it ends up becoming a massive undertaking to come up with a solution > that makes Linux in general a better operating system ;-) > > -- Steve > -- Ron Rechenmacher Engineer Fermi National Accelerator Laboratory Batavia, IL 60510