From: Steven Rostedt <rostedt@goodmis.org>
To: Tzvetomir Stoyanov <tz.stoyanov@gmail.com>
Cc: Linux Trace Devel <linux-trace-devel@vger.kernel.org>
Subject: Re: [PATCH 01/12] libtracefs: Add new internal APIs for dynamic events
Date: Thu, 28 Oct 2021 23:09:47 -0400 [thread overview]
Message-ID: <20211028230947.38f423c9@rorschach.local.home> (raw)
In-Reply-To: <CAPpZLN6NEHLSvu0jZE=3E5mhLZCX=zw7Sg+G-_6CXb=M38p1HQ@mail.gmail.com>
On Fri, 29 Oct 2021 05:46:42 +0300
Tzvetomir Stoyanov <tz.stoyanov@gmail.com> wrote:
> On Fri, Oct 29, 2021 at 12:41 AM Steven Rostedt <rostedt@goodmis.org> wrote:
> >
> > On Thu, 28 Oct 2021 15:08:56 +0300
> > "Tzvetomir Stoyanov (VMware)" <tz.stoyanov@gmail.com> wrote:
> >
> [...]
> > > +
> > > +struct tracefs_dynevent *
> > > +dynevent_alloc(enum trace_dynevent_type type, const char *system,
> > > + const char *event, const char *address, const char *format);
> > > +void dynevent_free(struct tracefs_dynevent *devent);
> > > +int dynevent_create(struct tracefs_dynevent *devent);
> > > +int dynevent_destroy(struct tracefs_dynevent *devent);
> > > +int dynevent_get_all(unsigned long type_mask, const char *system,
> > > + struct tracefs_dynevent ***ret_events);
> >
> > I usually prefer to have a list returned, and NULL on error, instead of
> > passing it in by reference. The "***" gets a bit out of hand.
> >
>
> The ret_events argument is optional, that's why it is passed as a
> parameter. If ret_events is NULL, the API will return only the count
> of the requested events. No array with events will be allocated in
> that case.
>
I would make a separate API for just the count, and not have this
function server two functionalities.
> >
> > > +
> > > #endif /* _TRACE_FS_LOCAL_H */
> > > diff --git a/include/tracefs.h b/include/tracefs.h
> > > index a2cda30..4020551 100644
> [ ... ]
> > > +
> > > +static int dyn_generic_parse(struct dyn_events_desc *desc, const char *group,
> > > + char *line, struct tracefs_dynevent **ret_dyn)
> >
> > Again, I prefer to have the pointer returned, and not assigned as a
> > parameter. All this returns is 0 on success or -1 on failure. That doesn't
> > give us anything more than having ret_dyn allocated or not. (return NULL or
> > non-NULL).
> >
>
> The ret_dyn is optional. If it is NULL, the function only checks if
> the line contains an event of the requested type, without allocating
> any memory.
I think we should make a separate API for that as well.
dyn_generic_parse_check()?
>
> > > +{
> > > + struct tracefs_dynevent *dyn;
> > > + char *address;
> > > + char *system;
> > > + char *format;
> > > + char *event;
> > > +
> > > + if (strncmp(line, desc->prefix, strlen(desc->prefix)))
> > > + return -1;
> > > +
> > > + system = strchr(line, ':');
> > > + if (!system)
> > > + return -1;
> > > + event = strchr(line, '/');
> > > + if (!event)
> > > + return -1;
> > > + address = strchr(line, ' ');
> > > + if (!address)
> > > + return -1;
> > > + format = strchr(address+1, ' ');
> > > +
> > > + *address = '\0';
> > > + *event = '\0';
> >
> >
> > The above should use strtok_r.
> >
> > char *probe;
> > char *sav;
> >
> > probe = strtok_r(line, ":", &sav);
> > system = strtok_r(NULL, "/", &sav);
> > event = strtok_r(NULL, " ", &sav);
> > address = strtok_r(NULL, " ", &sav);
> > format = strtok_r(NULL, "\n", &sav);
> >
>
> I used strchr() instead of strtok_r() here, because my original idea
> was that this function should not modify the original line string, if
> the event is not of the requested type. When parsing the
> "dynamic_events" file, it contains events from any types. My initial
> design was to pass the same line string to all parse functions, until
> there is a match. But the design was changed, now a new copy of the
> file is used for each event type. I'll change that code to use
> strtok_r().
>
> >
> >
> >
> > > +
> > > + /* KPROBEs and UPROBEs share the same prefix, check the format */
> > > + if (desc->type == TRACE_DYNEVENT_UPROBE || desc->type == TRACE_DYNEVENT_URETPROBE) {
> > > + if (!strchr(format, '/'))
> > > + return -1;
> > > + }
> [ ... ]
> > > +
> > > +static int get_all_type(enum trace_dynevent_type type, const char *system,
> > > + struct tracefs_dynevent ***ret_all)
> > > +{
> > > + struct dyn_events_desc *desc;
> > > + struct tracefs_dynevent *devent, **tmp, **all = NULL;
> > > + char *content;
> > > + int count = 0;
> > > + char *line;
> > > + char *next;
> > > + int ret;
> > > +
> > > + desc = get_devent_desc(type);
> > > + if (!desc)
> > > + return -1;
> > > +
> > > + content = tracefs_instance_file_read(NULL, desc->file, NULL);
> > > + if (!content)
> > > + return -1;
> >
> > space.
> >
> > > + line = content;
> > > + do {
> > > + next = strchr(line, '\n');
> > > + if (next)
> > > + *next = '\0';
> > > + ret = desc->dyn_events_parse(desc, system, line, ret_all ? &devent : NULL);
> >
> > So if ret_all is NULL, then we allocate a bunch of devent and lose them?
> >
>
> Hm, no devents are allocated if ret_all is NULL. That's the idea of
> that API design - ret_all is an optional input parameter. Without it,
> the functions can be used only to get the count of the requested
> events, without any memory allocation. I would like to keep that
> functionality, even though it is not used at the moment.
Ah. But still, this is overly complex to try to have this server two
functionalities. It becomes confusing.
>
> Thanks Steven! I'll address these comments in the next version, but I
> really want to keep the dynevent_get_all() API more flexible - to
> have a way to get only the count, without allocating an array with the
> events.
I really think you should have that as two separate functions,
otherwise it becomes overly complex.
-- Steve
next prev parent reply other threads:[~2021-10-29 3:09 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-28 12:08 [PATCH 00/12] libtracefs dynamic events support Tzvetomir Stoyanov (VMware)
2021-10-28 12:08 ` [PATCH 01/12] libtracefs: Add new internal APIs for dynamic events Tzvetomir Stoyanov (VMware)
2021-10-28 21:41 ` Steven Rostedt
2021-10-29 2:46 ` Tzvetomir Stoyanov
2021-10-29 3:09 ` Steven Rostedt [this message]
2021-10-28 12:08 ` [PATCH 02/12] libtracefs: Rename tracefs_get_kprobes API Tzvetomir Stoyanov (VMware)
2021-10-28 12:08 ` [PATCH 03/12] libtracefs: New kprobes APIs Tzvetomir Stoyanov (VMware)
2021-10-29 2:55 ` Steven Rostedt
2021-10-28 12:08 ` [PATCH 04/12] libtracefs: Remove redundant " Tzvetomir Stoyanov (VMware)
2021-10-28 12:09 ` [PATCH 05/12] libtracefs: Reimplement tracefs_kprobes_get API Tzvetomir Stoyanov (VMware)
2021-10-29 3:01 ` Steven Rostedt
2021-10-28 12:09 ` [PATCH 06/12] libtracefs: Change tracefs_kprobe_info API Tzvetomir Stoyanov (VMware)
2021-10-28 12:09 ` [PATCH 07/12] libtracefs: Reimplement kprobe raw APIs Tzvetomir Stoyanov (VMware)
2021-10-28 12:09 ` [PATCH 08/12] libtracefs: Extend kprobes unit test Tzvetomir Stoyanov (VMware)
2021-10-28 12:09 ` [PATCH 09/12] libtracefs: Update kprobes man pages Tzvetomir Stoyanov (VMware)
2021-10-28 12:09 ` [PATCH 10/12] libtracefs: Rename tracefs_synth_init API Tzvetomir Stoyanov (VMware)
2021-10-28 12:09 ` [PATCH 11/12] libtracefs: Use the internal dynamic events API when creating synthetic events Tzvetomir Stoyanov (VMware)
2021-10-28 12:09 ` [PATCH 12/12] libtracefs: Document tracefs_dynevent_list_free() API 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=20211028230947.38f423c9@rorschach.local.home \
--to=rostedt@goodmis.org \
--cc=linux-trace-devel@vger.kernel.org \
--cc=tz.stoyanov@gmail.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).