* Documentation/trace/events.rst: wrong numbering of sections @ 2020-05-15 7:43 Li Xinhai 2020-05-15 13:11 ` Steven Rostedt 0 siblings, 1 reply; 4+ messages in thread From: Li Xinhai @ 2020-05-15 7:43 UTC (permalink / raw) To: linux-trace-devel; +Cc: linux-kernel This document has below numbering of its sections: 1. Introduction 2. Using Event Tracing 2.1 Via the 'set_event' interface 2.2 Via the 'enable' toggle 2.3 Boot option 3. Defining an event-enabled tracepoint 4. Event formats 5. Event filtering 5.1 Expression syntax 5.2 Setting filters 5.3 Clearing filters 5.3 Subsystem filters 5.4 PID filtering 6. Event triggers 6.1 Expression syntax 6.2 Supported trigger commands 6.3 In-kernel trace event API 6.3.1 Dyamically creating synthetic event definitions 6.3.3 Tracing synthetic events from in-kernel code 6.3.3.1 Tracing a synthetic event all at once 6.3.3.1 Tracing a synthetic event piecewise 6.3.4 Dyamically creating kprobe and kretprobe event definitions 6.3.4 The "dynevent_cmd" low-level API It seems wrong numbering within 6.3 section. or, would it be better to have separated chapter #7, for 'In-kernel trace event API'? it seems not belong to 'Event triggers'. ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Documentation/trace/events.rst: wrong numbering of sections 2020-05-15 7:43 Documentation/trace/events.rst: wrong numbering of sections Li Xinhai @ 2020-05-15 13:11 ` Steven Rostedt 2020-05-15 18:22 ` Tom Zanussi 0 siblings, 1 reply; 4+ messages in thread From: Steven Rostedt @ 2020-05-15 13:11 UTC (permalink / raw) To: Li Xinhai Cc: linux-trace-devel, linux-kernel, Jonathan Corbet, Theodore Ts'o, Tom Zanussi It's best to Cc the maintainers of the file. Nobody reads linux-kernel (it produces 800 emails a day!). Luckily, I happen to monitor the linux-trace-devel list (which is mostly for userland tools), otherwise this email would have been lost to the LKML abyss. On Fri, 15 May 2020 15:43:43 +0800 "Li Xinhai" <lixinhai.lxh@gmail.com> wrote: > This document has below numbering of its sections: > > 1. Introduction > 2. Using Event Tracing > 2.1 Via the 'set_event' interface > 2.2 Via the 'enable' toggle > 2.3 Boot option > 3. Defining an event-enabled tracepoint > 4. Event formats > 5. Event filtering > 5.1 Expression syntax > 5.2 Setting filters > 5.3 Clearing filters > 5.3 Subsystem filters > 5.4 PID filtering > 6. Event triggers > 6.1 Expression syntax > 6.2 Supported trigger commands > 6.3 In-kernel trace event API > 6.3.1 Dyamically creating synthetic event definitions > 6.3.3 Tracing synthetic events from in-kernel code > 6.3.3.1 Tracing a synthetic event all at once > 6.3.3.1 Tracing a synthetic event piecewise > 6.3.4 Dyamically creating kprobe and kretprobe event definitions > 6.3.4 The "dynevent_cmd" low-level API > > It seems wrong numbering within 6.3 section. > or, would it be better to have separated chapter #7, for 'In-kernel trace > event API'? it seems not belong to 'Event triggers'. Yeah, 6.3.4 (both of them) probably should have been under a new top level section. (#7). -- Steve ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Documentation/trace/events.rst: wrong numbering of sections 2020-05-15 13:11 ` Steven Rostedt @ 2020-05-15 18:22 ` Tom Zanussi 2020-05-18 2:50 ` Li Xinhai 0 siblings, 1 reply; 4+ messages in thread From: Tom Zanussi @ 2020-05-15 18:22 UTC (permalink / raw) To: Steven Rostedt, Li Xinhai Cc: linux-trace-devel, linux-kernel, Jonathan Corbet, Theodore Ts'o Hi, On Fri, 2020-05-15 at 09:11 -0400, Steven Rostedt wrote: > It's best to Cc the maintainers of the file. Nobody reads linux- > kernel (it > produces 800 emails a day!). Luckily, I happen to monitor the > linux-trace-devel list (which is mostly for userland tools), > otherwise this > email would have been lost to the LKML abyss. > > On Fri, 15 May 2020 15:43:43 +0800 > "Li Xinhai" <lixinhai.lxh@gmail.com> wrote: > > > This document has below numbering of its sections: > > > > 1. Introduction > > 2. Using Event Tracing > > 2.1 Via the 'set_event' interface > > 2.2 Via the 'enable' toggle > > 2.3 Boot option > > 3. Defining an event-enabled tracepoint > > 4. Event formats > > 5. Event filtering > > 5.1 Expression syntax > > 5.2 Setting filters > > 5.3 Clearing filters > > 5.3 Subsystem filters > > 5.4 PID filtering > > 6. Event triggers > > 6.1 Expression syntax > > 6.2 Supported trigger commands > > 6.3 In-kernel trace event API > > 6.3.1 Dyamically creating synthetic event definitions > > 6.3.3 Tracing synthetic events from in-kernel code > > 6.3.3.1 Tracing a synthetic event all at once > > 6.3.3.1 Tracing a synthetic event piecewise > > 6.3.4 Dyamically creating kprobe and kretprobe event definitions > > 6.3.4 The "dynevent_cmd" low-level API > > > > It seems wrong numbering within 6.3 section. > > or, would it be better to have separated chapter #7, for 'In-kernel > > trace > > event API'? it seems not belong to 'Event triggers'. > > Yeah, 6.3.4 (both of them) probably should have been under a new top > level > section. (#7). > Yeah, aside from duplicate numbering in a couple of places, it would make more sense for everything starting from '6.3 In-kernel trace event API' to be in a section 7. Would you like to submit a patch for that, Li, or should I? Thanks, Tom > -- Steve ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Documentation/trace/events.rst: wrong numbering of sections 2020-05-15 18:22 ` Tom Zanussi @ 2020-05-18 2:50 ` Li Xinhai 0 siblings, 0 replies; 4+ messages in thread From: Li Xinhai @ 2020-05-18 2:50 UTC (permalink / raw) To: Tom Zanussi Cc: linux-trace-devel, linux-kernel, Jonathan Corbet, Theodore Ts'o, Steven Rostedt >Hi, > >On Fri, 2020-05-15 at 09:11 -0400, Steven Rostedt wrote: >> It's best to Cc the maintainers of the file. Nobody reads linux- >> kernel (it >> produces 800 emails a day!). Luckily, I happen to monitor the >> linux-trace-devel list (which is mostly for userland tools), >> otherwise this >> email would have been lost to the LKML abyss. >> >> On Fri, 15 May 2020 15:43:43 +0800 >> "Li Xinhai" <lixinhai.lxh@gmail.com> wrote: >> >> > This document has below numbering of its sections: >> > >> > 1. Introduction >> > 2. Using Event Tracing >> > 2.1 Via the 'set_event' interface >> > 2.2 Via the 'enable' toggle >> > 2.3 Boot option >> > 3. Defining an event-enabled tracepoint >> > 4. Event formats >> > 5. Event filtering >> > 5.1 Expression syntax >> > 5.2 Setting filters >> > 5.3 Clearing filters >> > 5.3 Subsystem filters >> > 5.4 PID filtering >> > 6. Event triggers >> > 6.1 Expression syntax >> > 6.2 Supported trigger commands >> > 6.3 In-kernel trace event API >> > 6.3.1 Dyamically creating synthetic event definitions >> > 6.3.3 Tracing synthetic events from in-kernel code >> > 6.3.3.1 Tracing a synthetic event all at once >> > 6.3.3.1 Tracing a synthetic event piecewise >> > 6.3.4 Dyamically creating kprobe and kretprobe event definitions >> > 6.3.4 The "dynevent_cmd" low-level API >> > >> > It seems wrong numbering within 6.3 section. >> > or, would it be better to have separated chapter #7, for 'In-kernel >> > trace >> > event API'? it seems not belong to 'Event triggers'. >> >> Yeah, 6.3.4 (both of them) probably should have been under a new top >> level >> section. (#7). >> > >Yeah, aside from duplicate numbering in a couple of places, it would >make more sense for everything starting from '6.3 In-kernel trace event >API' to be in a section 7. > >Would you like to submit a patch for that, Li, or should I? > I am not sure the correct organization of these part, you maybe better to fix it, thanks. >Thanks, > >Tom > >> -- Steve > ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2020-05-18 2:50 UTC | newest] Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-05-15 7:43 Documentation/trace/events.rst: wrong numbering of sections Li Xinhai 2020-05-15 13:11 ` Steven Rostedt 2020-05-15 18:22 ` Tom Zanussi 2020-05-18 2:50 ` Li Xinhai
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).