From: Steven Rostedt <firstname.lastname@example.org> To: Alexei Starovoitov <email@example.com> Cc: Kris Van Hees <firstname.lastname@example.org>, email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com Subject: Re: [RFC PATCH 00/11] bpf, trace, dtrace: DTrace BPF program type implementation and sample use Date: Thu, 23 May 2019 21:57:37 -0400 Message-ID: <firstname.lastname@example.org> (raw) In-Reply-To: <email@example.com> On Thu, 23 May 2019 17:31:50 -0700 Alexei Starovoitov <firstname.lastname@example.org> wrote: > > Now from what I'm reading, it seams that the Dtrace layer may be > > abstracting out fields from the kernel. This is actually something I > > have been thinking about to solve the "tracepoint abi" issue. There's > > usually basic ideas that happen. An interrupt goes off, there's a > > handler, etc. We could abstract that out that we trace when an > > interrupt goes off and the handler happens, and record the vector > > number, and/or what device it was for. We have tracepoints in the > > kernel that do this, but they do depend a bit on the implementation. > > Now, if we could get a layer that abstracts this information away from > > the implementation, then I think that's a *good* thing. > > I don't like this deferred irq idea at all. What do you mean deferred? > Abstracting details from the users is _never_ a good idea. Really? Most everything we do is to abstract details from the user. The key is to make the abstraction more meaningful than the raw data. > A ton of people use bcc scripts and bpftrace because they want those details. > They need to know what kernel is doing to make better decisions. > Delaying irq record is the opposite. I never said anything about delaying the record. Just getting the information that is needed. > > > > I wish that was totally true, but tracepoints *can* be an abi. I had > > code reverted because powertop required one to be a specific > > format. To this day, the wakeup event has a "success" field that > > writes in a hardcoded "1", because there's tools that depend on it, > > and they only work if there's a success field and the value is 1. > > I really think that you should put powertop nightmares to rest. > That was long ago. The kernel is different now. Is it? > Linus made it clear several times that it is ok to change _all_ > tracepoints. Period. Some maintainers somehow still don't believe > that they can do it. From what I remember him saying several times, is that you can change all tracepoints, but if it breaks a tool that is useful, then that change will get reverted. He will allow you to go and fix that tool and bring back the change (which was the solution to powertop). > > Some tracepoints are used more than others and more people will > complain: "ohh I need to change my script" when that tracepoint > changes. But the kernel development is not going to be hampered by a > tracepoint. No matter how widespread its usage in scripts. That's because we'll treat bpf (and Dtrace) scripts like modules (no abi), at least we better. But if there's a tool that doesn't use the script and reads the tracepoint directly via perf, then that's a different story. -- Steve > > Sometimes that pain of change can be mitigated a bit. Like that > 'success' field example, but tracepoints still change. > Meaningful value before vs hardcoded constant is still a breakage for > some scripts.
next prev parent reply index Thread overview: 54+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-05-20 23:47 Kris Van Hees 2019-05-21 17:56 ` Alexei Starovoitov 2019-05-21 18:41 ` Kris Van Hees 2019-05-21 20:55 ` Alexei Starovoitov 2019-05-21 21:36 ` Steven Rostedt 2019-05-21 21:43 ` Alexei Starovoitov 2019-05-21 21:48 ` Steven Rostedt 2019-05-22 5:23 ` Kris Van Hees 2019-05-22 20:53 ` Alexei Starovoitov 2019-05-23 5:46 ` Kris Van Hees 2019-05-23 21:13 ` Alexei Starovoitov 2019-05-23 23:02 ` Steven Rostedt 2019-05-24 0:31 ` Alexei Starovoitov 2019-05-24 1:57 ` Steven Rostedt [this message] 2019-05-24 2:08 ` Alexei Starovoitov 2019-05-24 2:40 ` Steven Rostedt 2019-05-24 5:26 ` Kris Van Hees 2019-05-24 5:10 ` Kris Van Hees 2019-05-24 4:05 ` Kris Van Hees 2019-05-24 13:28 ` Steven Rostedt 2019-05-21 21:36 ` Kris Van Hees 2019-05-21 23:26 ` Alexei Starovoitov 2019-05-22 4:12 ` Kris Van Hees 2019-05-22 20:16 ` Alexei Starovoitov 2019-05-23 5:16 ` Kris Van Hees 2019-05-23 20:28 ` Alexei Starovoitov 2019-05-30 16:15 ` Kris Van Hees 2019-05-31 15:25 ` Chris Mason 2019-06-06 20:58 ` Kris Van Hees 2019-06-18 1:25 ` Kris Van Hees 2019-06-18 1:32 ` Alexei Starovoitov 2019-06-18 1:54 ` Kris Van Hees 2019-06-18 3:01 ` Alexei Starovoitov 2019-06-18 3:19 ` Kris Van Hees 2019-05-22 14:25 ` Peter Zijlstra 2019-05-22 18:22 ` Kris Van Hees 2019-05-22 19:55 ` Alexei Starovoitov 2019-05-22 20:20 ` David Miller 2019-05-23 5:19 ` Kris Van Hees 2019-05-24 7:27 ` Peter Zijlstra 2019-05-21 20:39 ` [RFC PATCH 01/11] bpf: context casting for tail call Kris Van Hees 2019-05-21 20:39 ` [RFC PATCH 02/11] bpf: add BPF_PROG_TYPE_DTRACE Kris Van Hees 2019-05-21 20:39 ` [RFC PATCH 03/11] bpf: export proto for bpf_perf_event_output helper Kris Van Hees [not found] ` <facilities> 2019-05-21 20:39 ` [RFC PATCH 04/11] trace: initial implementation of DTrace based on kernel Kris Van Hees 2019-05-21 20:39 ` [RFC PATCH 05/11] trace: update Kconfig and Makefile to include DTrace Kris Van Hees [not found] ` <features> 2019-05-21 20:39 ` [RFC PATCH 06/11] dtrace: tiny userspace tool to exercise DTrace support Kris Van Hees 2019-05-21 20:39 ` [RFC PATCH 07/11] bpf: implement writable buffers in contexts Kris Van Hees 2019-05-21 20:39 ` [RFC PATCH 08/11] perf: add perf_output_begin_forward_in_page Kris Van Hees [not found] ` <the> [not found] ` <context> 2019-05-21 20:39 ` [RFC PATCH 09/11] bpf: mark helpers explicitly whether they may change Kris Van Hees [not found] ` <helpers> 2019-05-21 20:39 ` [RFC PATCH 10/11] bpf: add bpf_buffer_reserve and bpf_buffer_commit Kris Van Hees 2019-05-21 20:40 ` [RFC PATCH 11/11] dtrace: make use of writable buffers in BPF Kris Van Hees 2019-05-21 20:48 ` [RFC PATCH 00/11] bpf, trace, dtrace: DTrace BPF program type implementation and sample use Kris Van Hees 2019-05-21 20:54 ` Steven Rostedt 2019-05-21 20:56 ` Alexei Starovoitov
Reply instructions: You may reply publically 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 \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.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
BPF Archive on lore.kernel.org Archives are clonable: git clone --mirror https://lore.kernel.org/bpf/0 bpf/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 bpf bpf/ https://lore.kernel.org/bpf \ firstname.lastname@example.org email@example.com public-inbox-index bpf Newsgroup available over NNTP: nntp://nntp.lore.kernel.org/org.kernel.vger.bpf AGPL code for this site: git clone https://public-inbox.org/ public-inbox