From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754601AbbDUMZF (ORCPT ); Tue, 21 Apr 2015 08:25:05 -0400 Received: from mail03v-smtp01.fnal.gov ([131.225.199.28]:37201 "EHLO ex-smtp.fnal.gov" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1750960AbbDUMZC (ORCPT ); Tue, 21 Apr 2015 08:25:02 -0400 X-Greylist: delayed 328 seconds by postgrey-1.27 at vger.kernel.org; Tue, 21 Apr 2015 08:25:01 EDT Message-ID: <55364052.4050707@fnal.gov> Date: Tue, 21 Apr 2015 07:19:30 -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: Christoph Hellwig CC: , Steven Rostedt Subject: Re: [PATCH] tracing: Export key trace event symbols References: <553571C3.1060505@fnal.gov> <20150421061034.GA9253@infradead.org> <55363CDC.4000305@fnal.gov> In-Reply-To: <55363CDC.4000305@fnal.gov> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [99.141.209.99] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org I see in the reference I mentioned below (https://patches.linaro.org/28821/), and in the current mm source, that some tracepoint symbols are already EXPORTed, but not _GPL. I do not know the fine points between "GPL-ed" and "non-GPL-ed" symbol exporting. Would it make a difference if my patch proposed non-GPL exporting? Ron Rechenmacher wrote on 04/21/15 07:04: > > > Christoph Hellwig wrote on 04/21/15 01:10: >> >> Which (in-tree) module fails with this? I don't think anyone should >> actually register a symbol. >> > > I see you (Christoph Hellwig) have asked this question in a similar context > (see https://patches.linaro.org/28821/). > This question does not seem to make sense because: > 1) the external module is not registering a _symbol_ but more > precisely a tracepoint _function_ as the whole tracepoint system allows for > _multiple_ functions to be called for each tracepoint declared in the kernel. > 2) It's not the point that an in-tree module would fail. Again, the tracepoint > system allows for _multiple_functions_ to be defined/registered for each tracepoint > and _in_the_earlier_kernels_(i.e. 3.10.x and many others),_external_modules_could_ > _register_ one or more _additional_functions_ to be called. > > IF you're specifically saying that external modules should not register additional > tracepoint functions, my question would simply be: why do you think this? > > To give you an example of the usefulness of continuing to allow this (continuation > from earlier kernels): the kernel scheduling has a tracepoint defined; of course a > critical operation for any kernel. I use to be able to insert a module which would > collect my own statistics on when and what switching was going on on what CPU cores. > I can think of many other potential reasons that this would be useful for external > modules. To think that tracepoints would only be useful for in-tree development is, > perhaps, (not meaning to offend) short sighted. > -- Ron Rechenmacher Engineer Fermi National Accelerator Laboratory Batavia, IL 60510