All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ron Rechenmacher <ron@fnal.gov>
To: Christoph Hellwig <hch@infradead.org>
Cc: <linux-kernel@vger.kernel.org>, Steven Rostedt <rostedt@goodmis.org>
Subject: Re: [PATCH] tracing: Export key trace event symbols
Date: Tue, 21 Apr 2015 07:19:30 -0500	[thread overview]
Message-ID: <55364052.4050707@fnal.gov> (raw)
In-Reply-To: <55363CDC.4000305@fnal.gov>

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

  reply	other threads:[~2015-04-21 12:25 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-20 21:38 [PATCH] tracing: Export key trace event symbols Ron Rechenmacher
2015-04-21  6:10 ` Christoph Hellwig
2015-04-21 12:04   ` Ron Rechenmacher
2015-04-21 12:19     ` Ron Rechenmacher [this message]
2015-04-21 13:38       ` Steven Rostedt
2015-04-21 12:22     ` Christoph Hellwig
2015-04-21 13:13       ` Ron Rechenmacher
2015-04-21 13:23         ` Christoph Hellwig
2015-04-21 13:26           ` Ron Rechenmacher
2015-04-21 13:53             ` Steven Rostedt
2015-04-21 15:00               ` Ron Rechenmacher
2015-04-21 15:49                 ` Steven Rostedt
2015-04-21 22:23                   ` Ron Rechenmacher
2015-04-21 22:44                     ` Steven Rostedt
2015-04-22  2:24                       ` Ron Rechenmacher
2015-04-22 12:53                         ` Steven Rostedt
2015-04-22 12:55                           ` Steven Rostedt
2015-04-22 14:47                           ` Arnaldo Carvalho de Melo
2015-04-22 15:36                             ` David Ahern
2015-04-22 15:44                               ` Steven Rostedt
2015-04-22 16:35                                 ` Ron Rechenmacher
2015-04-22 17:00                                   ` Steven Rostedt
2015-04-23 15:28                               ` Pawel Moll
2015-04-23 15:33                                 ` Pawel Moll
2015-04-21 13:31           ` Steven Rostedt
2015-04-24 21:24 ` Steven Rostedt
2015-04-24 21:39   ` Mathieu Desnoyers
2015-04-27 19:12   ` Ron Rechenmacher

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=55364052.4050707@fnal.gov \
    --to=ron@fnal.gov \
    --cc=hch@infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rostedt@goodmis.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.