linux-trace-devel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Steven Rostedt <rostedt@goodmis.org>
To: Beau Belgrave <beaub@linux.microsoft.com>
Cc: linux-trace-devel@vger.kernel.org
Subject: Re: [PATCH v2 3/3] libtracefs: Add unit tests for user_events
Date: Wed, 23 Feb 2022 10:17:15 -0500	[thread overview]
Message-ID: <20220223101715.1009bd6f@gandalf.local.home> (raw)
In-Reply-To: <20220222232316.14640-4-beaub@linux.microsoft.com>

On Tue, 22 Feb 2022 15:23:16 -0800
Beau Belgrave <beaub@linux.microsoft.com> wrote:

> Adds unit tests for user_events when available. Ensures APIs are working
> correctly and appropriate errors are being returned.
> 
> Signed-off-by: Beau Belgrave <beaub@linux.microsoft.com>
> ---
>  utest/tracefs-utest.c | 233 ++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 233 insertions(+)
> 

OK, so I couldn't get the selftest working because I didn't have
user_events.h. I then worked to get that, but the selftest still failed
with:

After thinking about this a bit, I've decided that I'll release 1.3 without
this patch series.

The reason being, I want 1.3 to get into distros ASAP. As adding this patch
series will put a dependency on user_events.h (yes it builds without it,
but distros want everything that it can build applied), then that puts a
dependency on 1.3 to having user_events.h available, which may be a while
as it has to get into 5.18, and then slowly move to the distro kernels.

If distros did build it without user_events.h and then later on with
user_evnets.h then we have two versions of 1.3 where one supports
user_events and one does not. And you can not use versioning to determine
if your application will link to the library or not.

With all this in mind, I've decided to hold off this to libtracefs 1.4, and
when user_events is solidly in the kernel.

But I'm very excited to have this work in both the kernel and libtracefs. I
just want it properly done though.

Thanks for all your work and I'll keep these patches in my queue for 1.4.

Cheers,

-- Steve

  reply	other threads:[~2022-02-23 15:17 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-22 23:23 [PATCH v2 0/3] libtracefs: Add APIs for user_events to libtracefs Beau Belgrave
2022-02-22 23:23 ` [PATCH v2 1/3] libtracefs: Add user_events to libtracefs sources Beau Belgrave
2022-02-23  3:29   ` Steven Rostedt
2022-02-22 23:23 ` [PATCH v2 2/3] libtracefs: Add documentation and sample code for user_events Beau Belgrave
2022-02-22 23:23 ` [PATCH v2 3/3] libtracefs: Add unit tests " Beau Belgrave
2022-02-23 15:17   ` Steven Rostedt [this message]
2022-02-23 17:25     ` Beau Belgrave

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=20220223101715.1009bd6f@gandalf.local.home \
    --to=rostedt@goodmis.org \
    --cc=beaub@linux.microsoft.com \
    --cc=linux-trace-devel@vger.kernel.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 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).