public inbox for systemtap@sourceware.org
 help / color / mirror / Atom feed
From: "wcohen at redhat dot com" <sourceware-bugzilla@sourceware.org>
To: systemtap@sourceware.org
Subject: [Bug translator/23866] dissonance between kernel tracepoint parametrization, lkm vs bpf
Date: Thu, 18 Jul 2019 16:02:00 -0000	[thread overview]
Message-ID: <bug-23866-6586-a7nzJ0NrUv@http.sourceware.org/bugzilla/> (raw)
In-Reply-To: <bug-23866-6586@http.sourceware.org/bugzilla/>

https://sourceware.org/bugzilla/show_bug.cgi?id=23866

William Cohen <wcohen at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED

--- Comment #10 from William Cohen <wcohen at redhat dot com> ---
This should be addressed by the following commit:

commit fcdd71babea2435601e5e7f8b6b5faae4a663443
Author: William Cohen <wcohen@redhat.com>
Date:   Thu Jul 18 11:37:37 2019 -0400

    PR23866: Make the bpf backend use BPF raw tracepoints for kernel.trace("*")

    The BPF raw tracepoints provide arguments that better match the
    Systemtap lkm kernel tracepoint probes than regular BPF tracepoints.
    The BPF backend will use the BPF raw tracepoints unless the user
    specifies the old behavior with a --compatible=4.1 option on the
    commandline to address.

    The new BPF raw tracepoints and their argument are discovered in the
    same way as the old BPF tracepoints.  A number of small machine
    generated C files are generated with macros are compiled to query the
    available tracepoints in the kernel. Debug information describing the
    data structures passed into the BPF tracepoints is examined to
    determine the type and location of the tracepoint arguments.

    Each probe handler BPF code for BPF raw tracepoints is put into a
    raw_trace section as the method of registering the BPF raw tracepoints
    is different than the regular BPF tracepoints.

    The bpf tests have been revised to include the --compatible=4.1 option
    for the tests where it makes a difference.

-- 
You are receiving this mail because:
You are the assignee for the bug.

      parent reply	other threads:[~2019-07-18 16:02 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-06 21:31 [Bug translator/23866] New: " fche at redhat dot com
2019-06-10 14:53 ` [Bug translator/23866] " fche at redhat dot com
2019-06-10 15:58 ` wcohen at redhat dot com
2019-06-12 14:22 ` wcohen at redhat dot com
2019-06-19 15:02 ` wcohen at redhat dot com
2019-06-25 13:40 ` wcohen at redhat dot com
2019-07-10 15:02 ` wcohen at redhat dot com
2019-07-15 20:00 ` wcohen at redhat dot com
2019-07-16 18:20 ` wcohen at redhat dot com
2019-07-18 14:43 ` wcohen at redhat dot com
2019-07-18 16:02 ` wcohen at redhat dot com [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=bug-23866-6586-a7nzJ0NrUv@http.sourceware.org/bugzilla/ \
    --to=sourceware-bugzilla@sourceware.org \
    --cc=systemtap@sourceware.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 read-only IMAP folder(s) and NNTP newsgroup(s).