All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tzvetomir Stoyanov <tz.stoyanov@gmail.com>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: Linux Trace Devel <linux-trace-devel@vger.kernel.org>
Subject: Re: [PATCH 3/9] libtracefs man pages: APIs for locating trace directory and files.
Date: Mon, 21 Dec 2020 07:03:31 +0200	[thread overview]
Message-ID: <CAPpZLN6QSmUR5mV36FPyEwofUGNZB7ayzBr-EB20ruJaRcp5=Q@mail.gmail.com> (raw)
In-Reply-To: <20201220231011.0418e4ce@oasis.local.home>

On Mon, Dec 21, 2020 at 6:10 AM Steven Rostedt <rostedt@goodmis.org> wrote:
>
> On Mon, 21 Dec 2020 05:44:45 +0200
> Tzvetomir Stoyanov <tz.stoyanov@gmail.com> wrote:
>
> > > How should it be freed?
> > I'll add " with free()" in the next version of the patch, but I was
> > wondering if the
> > user should use "tracefs_put_tracing_file()" instead ? These APIs are not
> > consistent, may be they should be renamed.
>
> Good point.
>
> > Now we have:
> >
> >    tracefs_get_tracing_file() / tracefs_put_tracing_file()
> >    tracefs_get_tracing_dir() / returns static, must not be feed.
> >    tracefs_find_tracing_dir() / free()
>
> Perhaps we should change tracefs_get_tracing_dir() to simply:
> tracefs_tracing_dir().
>
>
> Hmm, what's the difference between "tracefs_find_tracing_dir() and
> tracefs_get_tracing_dir() (or what we will call tracefs_tracing_dir())?
>
> The only difference I see from the two descriptions is that one returns
> a cached string and the other returns just an allocated string. Do we
> even need tracefs_find_tracing_dir()?

The tracefs_find_tracing_dir() function is used in trace-cmd, but I agree that
it can be removed. I'll rename tracefs_get_tracing_dir() to
tracefs_tracing_dir()
and remove tracefs_find_tracing_dir() API. Going to change trace-cmd to use
only tracefs_tracing_dir() API.

>
> >
> >
> > >
> > > > +
> > > > +The _tracefs_get_tracing_dir()_ function returns the full path to the
> > > > +trace file system. In the first function call, the mount point of the
> > > > +tracing file system is located, cached and returned. It will mount it,
> > > > +if it is not minted. On any subsequent call the cached path is returned.
>
> Just noticed the above typo. s/minted/mounted/
>
> Although,  I wonder if a minted dir tastes good? ;-)
>
> -- Steve
>
> > > > +The return string must _not_ be freed.
> > > > +
> > > > +RETURN VALUE
> > > > +------------
> > > > +The _tracefs_get_tracing_file()_ function returns a string or NULL in case
> > > > +of an error. The returned string must be freed with _tracefs_put_tracing_file()_.
> > > > +
> > > > +The _tracefs_find_tracing_dir()_ function returns a string or NULL in case
> > > > +of an error. The returned string must be freed.
> > >
> > > Should state how it should be freed. tracefs_put_tracing_file() or free() ?
> > >
> > > If it is free(), then stating:
> > >
> > >  "The returned string must be freed with free()"
> > >
> > > is fine.
> > >
> > > > +
> > > > +The _tracefs_get_tracing_dir()_ function returns a constant string or NULL
> > > > +in case of an error. The returned string must _not_ be freed.
> > > > +
> > > > +EXAMPLE
> > > > +-------
> > > > +[source,c]
> > > > +--
> > > > +#include <tracefs.h>
> > > > +...
> > > > +char *trace_on = tracefs_get_tracing_file("tracing_on");
> > > > +     if (trace_on) {
> > > > +             ...
> > > > +             tracefs_put_tracing_file(trace_on);
> > > > +     }
> > > > +...
> > > > +char *trace_dir = tracefs_find_tracing_dir();
> > > > +     if (trace_dir) {
> > > > +             ...
> > > > +             free(trace_dir);
> > > > +     }
> > > > +...
> > > > +const char *trace_dir = tracefs_get_tracing_dir();
> > > > +
> > >
> > > Not a very useful example ;-)  We we can fix examples at a later time. I
> > > plan on writing a lot of example code to post, and some can make their way
> > > into the man pages.
> > >
> > > -- Steve
> >
> >
> >
>


-- 
Tzvetomir (Ceco) Stoyanov
VMware Open Source Technology Center

  reply	other threads:[~2020-12-21  5:04 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-17  9:46 [PATCH 0/9] libtracefs man pages Tzvetomir Stoyanov (VMware)
2020-12-17  9:46 ` [PATCH 1/9] libtracefs: Remove doc_gui targets Tzvetomir Stoyanov (VMware)
2020-12-18 19:24   ` Steven Rostedt
2020-12-17  9:46 ` [PATCH 2/9] libtracefs: Initial support for man pages Tzvetomir Stoyanov (VMware)
2020-12-18 18:49   ` Steven Rostedt
2020-12-17  9:46 ` [PATCH 3/9] libtracefs man pages: APIs for locating trace directory and files Tzvetomir Stoyanov (VMware)
2020-12-18 18:55   ` Steven Rostedt
2020-12-21  3:44     ` Tzvetomir Stoyanov
2020-12-21  4:10       ` Steven Rostedt
2020-12-21  5:03         ` Tzvetomir Stoyanov [this message]
2020-12-17  9:46 ` [PATCH 4/9] libtracefs man pages: APIs for working with trace systems and events Tzvetomir Stoyanov (VMware)
2020-12-18 19:23   ` Steven Rostedt
2020-12-17  9:46 ` [PATCH 5/9] libtracefs man pages: APIs for managing trace instances Tzvetomir Stoyanov (VMware)
2020-12-18 20:08   ` Steven Rostedt
2020-12-17  9:46 ` [PATCH 6/9] libtracefs man pages: APIs for working with files in " Tzvetomir Stoyanov (VMware)
2020-12-18 20:27   ` Steven Rostedt
2020-12-17  9:46 ` [PATCH 7/9] libtracefs man pages: helper APIs for working with " Tzvetomir Stoyanov (VMware)
2020-12-18 23:33   ` Steven Rostedt
2020-12-17  9:46 ` [PATCH 8/9] libtracefs man pages: APIs for initializing a tep handler with trace events from the local system Tzvetomir Stoyanov (VMware)
2020-12-17  9:46 ` [PATCH 9/9] libtracefs man pages: helper APIs for working with trace file system Tzvetomir Stoyanov (VMware)

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAPpZLN6QSmUR5mV36FPyEwofUGNZB7ayzBr-EB20ruJaRcp5=Q@mail.gmail.com' \
    --to=tz.stoyanov@gmail.com \
    --cc=linux-trace-devel@vger.kernel.org \
    --cc=rostedt@goodmis.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.