> On Mar 8, 2019, at 5:36 AM, Tzvetomir Stoyanov <tstoyanov@xxxxxxxxxx> wrote:
>
> Create man page for tep_data_lat_fmt()
> as part of the libtraceevent APIs.
>
> Signed-off-by: Tzvetomir Stoyanov <tstoyanov@xxxxxxxxxx>
> ---
> .../libtraceevent-record_lat.txt | 77 +++++++++++++++++++
> 1 file changed, 77 insertions(+)
> create mode 100644 tools/lib/traceevent/Documentation/libtraceevent-record_lat.txt
>
> diff --git a/tools/lib/traceevent/Documentation/libtraceevent-record_lat.txt b/tools/lib/traceevent/Documentation/libtraceevent-record_lat.txt
> new file mode 100644
> index 000000000000..f4e37b186f61
> --- /dev/null
> +++ b/tools/lib/traceevent/Documentation/libtraceevent-record_lat.txt
> @@ -0,0 +1,77 @@
> +libtraceevent(3)
> +================
> +
> +NAME
> +----
> +tep_data_lat_fmt - Parses the data for the latency format.
It’s not exactly an issue with this man page but I notice that, unlike a sampling of libtraceevent API function names in this series, this one is quite abbreviated. Is it called very often? Would it make sense to rename it to be as clear as the other function names?
tep_data_latency_format
seems much clearer to me.
> +
> +SYNOPSIS
> +--------
> +[verse]
> +--
> +*#include <event-parse.h>*
> +
> +void *tep_data_lat_fmt*(struct tep_handle pass:[*]_tep_, struct trace_seq pass:[*]_s_, struct tep_record pass:[*]_record_);
> +--
> +DESCRIPTION
> +-----------
> +The _tep_data_lat_fmt()_ function parses out the latency format (interrupts
> +disabled, need rescheduling, in hard/soft interrupt, preempt count and
> +lock depth) from _record_ and places it into the _s_. The _tep_ argument is
> +the trace event parser context.
This one is missing the RETURN VALUE section.
Cheers,
-Matt
|