Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Thu, 21 Jul 2022 22:57:12 +0800
From:   Tao Zhou <tao.zhou@linux.dev>
To:     Daniel Bristot de Oliveira <bristot@kernel.org>
Cc:     Steven Rostedt <rostedt@goodmis.org>,
        Wim Van Sebroeck <wim@linux-watchdog.org>,
        Guenter Roeck <linux@roeck-us.net>,
        Jonathan Corbet <corbet@lwn.net>,
        Ingo Molnar <mingo@redhat.com>,
        Thomas Gleixner <tglx@linutronix.de>,
        Peter Zijlstra <peterz@infradead.org>,
        Will Deacon <will@kernel.org>,
        Catalin Marinas <catalin.marinas@arm.com>,
        Marco Elver <elver@google.com>,
        Dmitry Vyukov <dvyukov@google.com>,
        "Paul E. McKenney" <paulmck@kernel.org>,
        Shuah Khan <skhan@linuxfoundation.org>,
        Gabriele Paoloni <gpaoloni@redhat.com>,
        Juri Lelli <juri.lelli@redhat.com>,
        Clark Williams <williams@redhat.com>,
        Randy Dunlap <rdunlap@infradead.org>,
        linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
        linux-trace-devel@vger.kernel.org, Tao Zhou <tao.zhou@linux.dev>
Subject: Re: [PATCH V6 11/16] Documentation/rv: Add deterministic automata
 instrumentation documentation
Message-ID: <YtlpSGp590YJXT22@geo.homenetwork>
References: <cover.1658244826.git.bristot@kernel.org>
 <3c915ffd00f033d57dbac2f69e56a87b7b80adba.1658244826.git.bristot@kernel.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <3c915ffd00f033d57dbac2f69e56a87b7b80adba.1658244826.git.bristot@kernel.org>
Precedence: bulk

On Tue, Jul 19, 2022 at 07:27:16PM +0200, Daniel Bristot de Oliveira wrote:

> +Looking at the automata definition, it is possible to see that the system
> +and the model are expected to return to the initial state after the
> +preempt_enable execution. Hence, it can be used to synchronize the
> +system and the model at the initialization of the monitoring section.
> +
> +The start is informed via a special handle function, the
> +"da_handle_start_event_MONITOR_event)", in this case::

da_handle_start_event_$MONITOR(event) the same as the previous version
should be right.

> +
> +  da_handle_start_event_wip(preempt_disable_wip);

I didn't see this in last version that the event should be preempt_enable_wip.

> +
> +So, the callback function will look like::
> +
> +  void handle_preempt_enable(void *data, unsigned long ip, unsigned long parent_ip)
> +  {
> +        da_handle_start_event_wip(preempt_enable_wip);
> +  }
> +
> +Finally, the "handle_sched_waking()" will look like::
> +
> +  void handle_sched_waking(void *data, struct task_struct *task)
> +  {
> +        da_handle_event_wip(sched_waking_wip);
> +  }
> +
> +And the explanation is left for the reader as an exercise.
> +
> +Start and Stop functions

Start and Stop functions are changed to enable and disable functions.

> +------------------------
> +
> +dot2k automatically creates two special functions::
> +
> +  enable_MONITOR()
> +  disable_MONITOR()
> +
> +These functions are called when the monitor is enabled and disabled,
> +respectively.
> +
> +They should be used to *attach* and *detach* the instrumentation to the running
> +system. The developer must add to the relative function all that is needed to
> +*attach* and *detach* its monitor to the system.
> +
> +For the wip case, these functions were named::
> +
> + enable_wip()
> + disable_wip()
> +
> +But no change was required because: by default, these functions *attach* and
> +*detach* the tracepoints_to_attach, which was enough for this case.