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] trace-cmd: Implement warning() in the library
Date: Mon, 5 Apr 2021 10:23:16 -0400	[thread overview]
Message-ID: <20210405102316.5d28cc58@gandalf.local.home> (raw)
In-Reply-To: <20210405095920.526d8922@gandalf.local.home>

On Mon, 5 Apr 2021 09:59:20 -0400
Steven Rostedt <rostedt@goodmis.org> wrote:

> On Mon,  5 Apr 2021 12:33:57 +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. Added a weak implementation in the library, in
> > case the function in not implemented in the application, using that
> > library.
> >   
> 
> Isn't the "warning()" function implemented in libtraceevent? That's where
> it would be used as it is weak there.
> 
> But honestly, I think we should change the libtraceveent warning to
> "tep_warning()" if we haven't already done so.
> 
> /me goes to look at the code.

OK, so what I think we need to do is have this:


void __weak tep_print_error(const char *fmt, const char *app, va_list ap)
{
	if (errno)
		perror(app);
	fprintf(stderr, " ");
	vfprintf(stderr, fmt, ap);
	fprintf(stderr, "\n");
}

That gets the format and a va_list, and this is the weak function that
anything can overwrite (like KernelShark to have a pop up on error?).

Then we can have functions:

void __weak tep_vwarning(const char *fmt, va_list ap)
{
	tep_print_error(fmt, "libtraceevent", ap);
}
	
void __weak tep_warning(const char *fmt, ...)
{
	va_list ap;

	va_start(ap, fmt);
	tep_vwarning(fmt, ap);
	va_end(ap);
}


And the same for libtracefs and libtracecmd.

where it will have a tracefs_warning() and a tracecmd_warning() functions
defined. Then an app can overwrite how tep_print_error() works, as well as
tep_vwarning works (or tracefs_vwarning() etc).

Hmm, thinking about this, there's no reason to have tep_warning() weak,
because by overwriting tep_vwarning(), you have full control of
tep_warning().

-- Steve

      reply	other threads:[~2021-04-05 14:23 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-05  9:33 [PATCH] trace-cmd: Implement warning() in the library Tzvetomir Stoyanov (VMware)
2021-04-05 13:59 ` Steven Rostedt
2021-04-05 14:23   ` Steven Rostedt [this message]

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=20210405102316.5d28cc58@gandalf.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.