Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Message-ID: <2449de9a39bd09510f75bd2358cc7ddfd397e93f.camel@kernel.org>
Subject: Re: Documentation/trace/events.rst: wrong numbering of sections
From:   Tom Zanussi <zanussi@kernel.org>
To:     Steven Rostedt <rostedt@goodmis.org>,
        Li Xinhai <lixinhai.lxh@gmail.com>
Cc:     linux-trace-devel <linux-trace-devel@vger.kernel.org>,
        linux-kernel <linux-kernel@vger.kernel.org>,
        Jonathan Corbet <corbet@lwn.net>, Theodore Ts'o <tytso@mit.edu>
Date:   Fri, 15 May 2020 13:22:42 -0500
In-Reply-To: <20200515091126.75db6ec9@gandalf.local.home>
References: <2020051515434115672512@gmail.com>
         <20200515091126.75db6ec9@gandalf.local.home>
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

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