All of lore.kernel.org
 help / color / mirror / Atom feed
From: Steven Rostedt <rostedt@goodmis.org>
To: "Tzvetomir Stoyanov (VMware)" <tz.stoyanov@gmail.com>
Cc: linux-trace-devel@vger.kernel.org
Subject: Re: [PATCH v3] trace-cmd: Implement warning() in the library
Date: Thu, 8 Apr 2021 19:57:38 -0400	[thread overview]
Message-ID: <20210408195738.5910fd96@oasis.local.home> (raw)
In-Reply-To: <20210408042843.3112349-1-tz.stoyanov@gmail.com>

On Thu,  8 Apr 2021 07:28:43 +0300
"Tzvetomir Stoyanov (VMware)" <tz.stoyanov@gmail.com> wrote:

> The warning() function is used in a lot of places in the trace-cmd
> library, but there is no implementation. The function is implemented in
> the trace-cmd application. There is also a weak implementation in
> traceevent library, which is specific to that library.
> Implemented a new tracecmd_lib_warning(), specific to the trace-cmd
> library and replaced all warning() calls with the new function in the
> library. The new function is implemented as weak, so it can be
> overridden by the application.
> The tracecm_lib_warning() uses tep_vwarning() from libtraceevent for
> printing the warning, which is also a weak function and can be
> overridden by the application.

Hmm, this seems inconsistent with the other warnings. We have
tep_warning(), tracefs_warning, and here it's tracecmd_lib_warning(). I
wonder if it's better to drop the "_lib" part, and just call it,
tracecmd_warning()?

And if we do, we should rename tracecmd_lib_fatal() to just
tracecmd_fatal(). The "lib" just seems redundant.

-- Steve

  reply	other threads:[~2021-04-08 23:57 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-08  4:28 [PATCH v3] trace-cmd: Implement warning() in the library Tzvetomir Stoyanov (VMware)
2021-04-08 23:57 ` Steven Rostedt [this message]
2021-04-09  4:27   ` Tzvetomir Stoyanov

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=20210408195738.5910fd96@oasis.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 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.