docs: trace: events.rst: convert some new stuff to ReST format

differences and the implementation isn't currently tied to it in any

way, so beware about making generalizations between the two.

Note: Writing into trace_marker (See Documentation/trace/ftrace.rst)

.. Note::

     Writing into trace_marker (See Documentation/trace/ftrace.rst)

     can also enable triggers that are written into

     /sys/kernel/tracing/events/ftrace/print/trigger

In this method, the name of the event to create and an array defining

the fields is supplied to synth_event_create().  If successful, a

synthetic event with that name and fields will exist following that

call.  For example, to create a new "schedtest" synthetic event:

call.  For example, to create a new "schedtest" synthetic event::

  ret = synth_event_create("schedtest", sched_fields,

                           ARRAY_SIZE(sched_fields), THIS_MODULE);

The sched_fields param in this example points to an array of struct

synth_field_desc, each of which describes an event field by type and

name:

name::

  static struct synth_field_desc sched_fields[] = {

        { .type = "pid_t",              .name = "next_pid_field" },

initialize a dynevent_cmd object using synth_event_cmd_init().

For example, to create a new "schedtest" synthetic event with two

fields:

fields::

  struct dynevent_cmd cmd;

  char *buf;

                                  "u64", "ts_ns");

Alternatively, using an array of struct synth_field_desc fields

containing the same information:

containing the same information::

  ret = synth_event_gen_cmd_array_start(&cmd, "schedtest", THIS_MODULE,

                                        fields, n_fields);

populated with more fields.  Fields are added one by one using

synth_event_add_field(), supplying the dynevent_cmd object, a field

type, and a field name.  For example, to add a new int field named

"intfield", the following call should be made:

"intfield", the following call should be made::

  ret = synth_event_add_field(&cmd, "int", "intfield");

A group of fields can also be added all at once using an array of

synth_field_desc with add_synth_fields().  For example, this would add

just the first four sched_fields:

just the first four sched_fields::

  ret = synth_event_add_fields(&cmd, sched_fields, 4);

also automatically append a ';' to the string.

Once all the fields have been added, the event should be finalized and

registered by calling the synth_event_gen_cmd_end() function:

registered by calling the synth_event_gen_cmd_end() function::

  ret = synth_event_gen_cmd_end(&cmd);

synthetic event field, and the number of values being passed.

So, to trace an event corresponding to the synthetic event definition

above, code like the following could be used:

above, code like the following could be used::

  ret = synth_event_trace(create_synth_test, 7, /* number of values */

                          444,             /* next_pid_field */

event field.

To trace an event corresponding to the synthetic event definition

above, code like the following could be used:

above, code like the following could be used::

  u64 vals[7];

is needed.  The trace_get_event_file() function can be used to get

it - it will find the file in the given trace instance (in this case

NULL since the top trace array is being used) while at the same time

preventing the instance containing it from going away:

preventing the instance containing it from going away::

       schedtest_event_file = trace_get_event_file(NULL, "synthetic",

                                                   "schedtest");

can be used (which is not specific to synthetic events, so does need

the "synthetic" system name to be specified explicitly).

To enable the event, pass 'true' to it:

To enable the event, pass 'true' to it::

       trace_array_set_clr_event(schedtest_event_file->tr,

                                 "synthetic", "schedtest", true);

To disable it pass false:

To disable it pass false::

       trace_array_set_clr_event(schedtest_event_file->tr,

                                 "synthetic", "schedtest", false);

Finally, synth_event_trace_array() can be used to actually trace the

event, which should be visible in the trace buffer afterwards:

event, which should be visible in the trace buffer afterwards::

       ret = synth_event_trace_array(schedtest_event_file, vals,

                                     ARRAY_SIZE(vals));

To remove the synthetic event, the event should be disabled, and the

trace instance should be 'put' back using trace_put_event_file():

trace instance should be 'put' back using trace_put_event_file()::

       trace_array_set_clr_event(schedtest_event_file->tr,

                                 "synthetic", "schedtest", false);

       trace_put_event_file(schedtest_event_file);

If those have been successful, synth_event_delete() can be called to

remove the event:

remove the event::

       ret = synth_event_delete("schedtest");

To trace a synthetic using the piecewise method described above, the

synth_event_trace_start() function is used to 'open' the synthetic

event trace:

event trace::

       struct synth_trace_state trace_state;

field is set, the 'cursor' points to the next field, which will be set

by the subsequent call, continuing until all the fields have been set

in order.  The same sequence of calls as in the above examples using

this method would be (without error-handling code):

this method would be (without error-handling code)::

       /* next_pid_field */

       ret = synth_event_add_next_val(777, &trace_state);

the synth_event_trace_start(), along with the field name of the field

to set and the value to set it to.  The same sequence of calls as in

the above examples using this method would be (without error-handling

code):

code)::

       ret = synth_event_add_val("next_pid_field", 777, &trace_state);

       ret = synth_event_add_val("next_comm_field", (u64)"silly putty",

Finally, the event won't be actually traced until it's 'closed',

which is done using synth_event_trace_end(), which takes only the

struct synth_trace_state object used in the previous calls:

struct synth_trace_state object used in the previous calls::

       ret = synth_event_trace_end(&trace_state);

should create and initialize a dynevent_cmd object using

kprobe_event_cmd_init().

For example, to create a new "schedtest" kprobe event with two fields:

For example, to create a new "schedtest" kprobe event with two fields::

  struct dynevent_cmd cmd;

  char *buf;

populated with more fields.  Fields can be added using

kprobe_event_add_fields(), supplying the dynevent_cmd object along

with a variable arg list of probe fields.  For example, to add a

couple additional fields, the following call could be made:

couple additional fields, the following call could be made::

  ret = kprobe_event_add_fields(&cmd, "flags=%cx", "mode=+4($stack)");

Once all the fields have been added, the event should be finalized and

registered by calling the kprobe_event_gen_cmd_end() or

kretprobe_event_gen_cmd_end() functions, depending on whether a kprobe

or kretprobe command was started:

or kretprobe command was started::

  ret = kprobe_event_gen_cmd_end(&cmd);

or

or::

  ret = kretprobe_event_gen_cmd_end(&cmd);

Similarly, a kretprobe event can be created using

kretprobe_event_gen_cmd_start() with a probe name and location and

additional params such as $retval:

additional params such as $retval::

  ret = kretprobe_event_gen_cmd_start(&cmd, "gen_kretprobe_test",

                                      "do_sys_open", "$retval");

Similar to the synthetic event case, code like the following can be

used to enable the newly created kprobe event:

used to enable the newly created kprobe event::

  gen_kprobe_test = trace_get_event_file(NULL, "kprobes", "gen_kprobe_test");

                                  "kprobes", "gen_kprobe_test", true);

Finally, also similar to synthetic events, the following code can be

used to give the kprobe event file back and delete the event:

used to give the kprobe event file back and delete the event::

  trace_put_event_file(gen_kprobe_test);

The first step in building a new command string is to create and

initialize an instance of a dynevent_cmd.  Here, for instance, we

create a dynevent_cmd on the stack and initialize it:

create a dynevent_cmd on the stack and initialize it::

  struct dynevent_cmd cmd;

  char *buf;

To add a single argument, define and initialize a struct dynevent_arg

or struct dynevent_arg_pair object.  Here's an example of the simplest

possible arg addition, which is simply to append the given string as

a whitespace-separated argument to the command:

a whitespace-separated argument to the command::

  struct dynevent_arg arg;

Here's another more complicated example using an 'arg pair', which is

used to create an argument that consists of a couple components added

together as a unit, for example, a 'type field_name;' arg or a simple

expression arg e.g. 'flags=%cx':

expression arg e.g. 'flags=%cx'::

  struct dynevent_arg_pair arg_pair;

(until its length surpasses cmd->maxlen).  When all the arguments have

been added and the command string is complete, the only thing left to

do is run the command, which happens by simply calling

dynevent_create():

dynevent_create()::

  ret = dynevent_create(&cmd);