linux-kernel - Re: Documentation/trace/events.rst: wrong numbering of sections

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20200515091126.75db6ec9@gandalf.local.home>
Date:   Fri, 15 May 2020 09:11:26 -0400
From:   Steven Rostedt <rostedt@...dmis.org>
To:     "Li Xinhai" <lixinhai.lxh@...il.com>
Cc:     linux-trace-devel <linux-trace-devel@...r.kernel.org>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        Jonathan Corbet <corbet@....net>,
        Theodore Ts'o <tytso@....edu>, Tom Zanussi <zanussi@...nel.org>
Subject: Re: Documentation/trace/events.rst: wrong numbering of sections


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@...il.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