Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1685909
| From | Tom Zanussi <tom.zanussi@linux.intel.com> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: Dynamic tracepoints in 4.11.8-rt5 |
| Date | 2017-07-12 18:50 +0200 |
| Message-ID | <u2sZQ-2cp-7@gated-at.bofh.it> (permalink) |
| References | <u2sds-1H6-25@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
Hi Mathieu, On Wed, 2017-07-12 at 15:56 +0000, Mathieu Desnoyers wrote: > Hi Tom, > > I notice this commit appears in linux-rt-devel 4.11.8-rt5 > (and it is not in upstream Linux): > > 003100371 tracing: Add support for dynamic tracepoints > > It adds a "bool dynamic" argument to tracepoint_probe_unregister. > > I'm trying to figure out why this change is introduced as a new API > "dynamic_tracepoint_probe_register()" and by adding a boolean > to tracepoint_probe_unregister(). > > Allowing the user of register API to mixup between dynamic > and non-dynamic boolean values for the same tracepoint instance > seems fragile. > > Given that the "dynamic" nature of this new kind of tracepoint > appears to be associated with the tracepoint instance > (struct tracepoint), why can't we simply add a "bool dynamic" > field to struct tracepoint, so we can deal with this internally > within tracepoint.c without exposing this detail in the register > API ? > Yeah, I think that should work - I'm working on an update to these patches and will make that change. Thanks, Tom > This would also take care of currently diverging module APIs for the > GPL-exported symbol tracepoint_unregister() between Linux upstream > and linux-rt. > > Thanks, > > Mathieu >
Back to linux.kernel | Previous | Next — Previous in thread | Find similar | Unroll thread
Dynamic tracepoints in 4.11.8-rt5 Mathieu Desnoyers <mathieu.desnoyers@efficios.com> - 2017-07-12 18:00 +0200 Re: Dynamic tracepoints in 4.11.8-rt5 Tom Zanussi <tom.zanussi@linux.intel.com> - 2017-07-12 18:50 +0200
csiph-web