Re: [PATCH v2] perf/sdt: Show proper hint

[Ingo Molnar <mingo@kernel.org>]

* Arnaldo Carvalho de Melo <acme@redhat.com> wrote:

> Em Fri, Feb 03, 2017 at 03:56:42PM +0530, Ravi Bangoria escreveu:
> > After patch:
> >   $ perf record -a -e sdt_glib:idle__add
> >     event syntax error: 'sdt_glib:idle__add'
> >                          \___ unknown tracepoint
> > 
> >     Error: File /sys/kernel/debug/tracing/events/sdt_glib/idle__add not found.
> >     Hint:  SDT event cannot be directly recorded on. Please use 'perf probe sdt_glib:idle__add' before recording it.
> >     ...
> > 
> >   $ perf probe sdt_glib:idle__add
> >     Added new event:
> >       sdt_glib:idle__add   (on %idle__add in /usr/lib64/libglib-2.0.so.0.5000.2)
> > 
> >     You can now use it in all perf tools, such as:
> > 
> >         perf record -e sdt_glib:idle__add -aR sleep 1
> > 
> >   $ perf record -a -e sdt_glib:idle__add
> >     [ perf record: Woken up 1 times to write data ]
> >     [ perf record: Captured and wrote 0.175 MB perf.data ]
> 
> Looks much better! Thanks!
> 
> Unsure if we should state somewhere that this needs to be done only once
> per boot.

Forgot to reply to your question - indeed I agree that something like this would 
be even better:

   $ perf record -a -e sdt_glib:idle__add
     event syntax error: 'sdt_glib:idle__add'
                          \___ unknown tracepoint
 
     Error: File /sys/kernel/debug/tracing/events/sdt_glib/idle__add not found.
     Hint:  SDT event cannot be directly recorded on.
            Please first use 'perf probe sdt_glib:idle__add' before recording it.

BTW., and I think this is fundamental: why is this interim step forced upon the 
user - cannot we just auto-enable it if it's not enabled yet?

If for some reason it's important for the user to know that we enabled a probe we 
could print that we did so:

     Info: enabling not yet enabled 'perf probe sdt_glib:idle__add' SDT event.

... and that would be even more usable.

A tool printing out the perfect thing for the user to type in is a sign that the 
tool should have done this itself.

See for example how Git handles the bisection workflow. Technically the following 
is required to start a bisection:

  triton:~/tip> git bisect start
  triton:~/tip> git bisect bad
  triton:~/tip> 

But you can also do:

  triton:~/tip> git bisect bad
  You need to start by "git bisect start"
  Do you want me to do it for you [Y/n]? 
  triton:~/tip> 

and the user can start the bisection by hitting Enter.

No fuss, no unnecessary resistance from tooling - and the user is fully informed 
all along. Every extra tooling step forced upon users annoys them and shrinks the 
potential userbase.

Thanks,

	Ingo