From: Kris Van Hees <kris.van.hees@oracle.com>
To: Chris Mason <clm@fb.com>
Cc: Kris Van Hees <kris.van.hees@oracle.com>,
Alexei Starovoitov <alexei.starovoitov@gmail.com>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
"bpf@vger.kernel.org" <bpf@vger.kernel.org>,
"dtrace-devel@oss.oracle.com" <dtrace-devel@oss.oracle.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"rostedt@goodmis.org" <rostedt@goodmis.org>,
"mhiramat@kernel.org" <mhiramat@kernel.org>,
"acme@kernel.org" <acme@kernel.org>,
"ast@kernel.org" <ast@kernel.org>,
"daniel@iogearbox.net" <daniel@iogearbox.net>,
"peterz@infradead.org" <peterz@infradead.org>
Subject: Re: [RFC PATCH 00/11] bpf, trace, dtrace: DTrace BPF program type implementation and sample use
Date: Thu, 6 Jun 2019 16:58:51 -0400 [thread overview]
Message-ID: <20190606205851.GI11035@oracle.com> (raw)
In-Reply-To: <5AD44AC7-F88F-4068-B122-962839F968B2@fb.com>
On Fri, May 31, 2019 at 03:25:25PM +0000, Chris Mason wrote:
>
> I'm being pretty liberal with chopping down quoted material to help
> emphasize a particular opinion about how to bootstrap existing
> out-of-tree projects into the kernel. My goal here is to talk more
> about the process and less about the technical details, so please
> forgive me if I've ignored or changed the technical meaning of anything
> below.
>
> On 30 May 2019, at 12:15, Kris Van Hees wrote:
>
> > On Thu, May 23, 2019 at 01:28:44PM -0700, Alexei Starovoitov wrote:
> >
> > ... I believe that the discussion that has been going on in other
> > emails has shown that while introducing a program type that provides a
> > generic (abstracted) context is a different approach from what has
> > been done
> > so far, it is a new use case that provides for additional ways in
> > which BPF
> > can be used.
> >
>
> [ ... ]
>
> >
> > Yes and no. It depends on what you are trying to do with the BPF
> > program that
> > is attached to the different events. From a tracing perspective,
> > providing a
> > single BPF program with an abstract context would ...
>
> [ ... ]
>
> >
> > In this model kprobe/ksys_write and
> > tracepoint/syscalls/sys_enter_write are
> > equivalent for most tracing purposes ...
>
> [ ... ]
>
> >
> > I agree with what you are saying but I am presenting an additional use
> > case
>
> [ ... ]
>
> >>
> >> All that aside the kernel support for shared libraries is an awesome
> >> feature to have and a bunch of folks want to see it happen, but
> >> it's not a blocker for 'dtrace to bpf' user space work.
> >> libbpf can be taught to do this 'pseudo shared library' feature
> >> while 'dtrace to bpf' side doesn't need to do anything special.
>
> [ ... ]
>
> This thread intermixes some abstract conceptual changes with smaller
> technical improvements, and in general it follows a familiar pattern
> other out-of-tree projects have hit while trying to adapt the kernel to
> their existing code. Just from this one email, I quoted the abstract
> models with use cases etc, and this is often where the discussions side
> track into less productive areas.
>
> >
> > So you are basically saying that I should redesign DTrace?
>
> In your place, I would have removed features and adapted dtrace as much
> as possible to require the absolute minimum of kernel patches, or even
> better, no patches at all. I'd document all of the features that worked
> as expected, and underline anything either missing or suboptimal that
> needed additional kernel changes. Then I'd focus on expanding the
> community of people using dtrace against the mainline kernel, and work
> through the series features and improvements one by one upstream over
> time.
Well, that is actually what I am doing in the sense that the proposed patches
are quite minimal and lie at the core of the style of tracing that we need to
support. So I definitely agree with your statement. The code I posted
implements a minimal set of features (hardly any at all), although as Peter
pointed out, some more can be stripped from it and I have done that already
in a revision of the patchset I was preparing.
> Your current approach relies on an all-or-nothing landing of patches
> upstream, and this consistently leads to conflict every time a project
> tries it. A more incremental approach will require bigger changes on
> the dtrace application side, but over time it'll be much easier to
> justify your kernel changes. You won't have to talk in abstract models,
> and you'll have many more concrete examples of people asking for dtrace
> features against mainline. Most importantly, you'll make dtrace
> available on more kernels than just the absolute latest mainline, and
> removing dependencies makes the project much easier for new users to
> try.
I am not sure where I gave the impression that my approach relies on an
all-or-nothing landing of patches. My intent (and the content of the patches
reflects that I think) was to work from a minimal base and build on that,
adding things as needed. Granted, it depends on a rather crucial feature in
the design that apparently should be avoided for now as well, and I can
definitely work on avoiding that for now. But I hope that it is clear from
the patch set I posted that an incremental approach is indeed what I intend
to do.
Thank you for putting it in clear terms and explaining patfalls that have
be observed in the past with projects. I will proceed with an even more
minimalist approach.
To that end, could you advice on who patches should be Cc'd to to have the
first minimal code submitted to a tools/dtrace directory in the kernel tree?
Kris
next prev parent reply other threads:[~2019-06-06 21:00 UTC|newest]
Thread overview: 54+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-05-20 23:47 [RFC PATCH 00/11] bpf, trace, dtrace: DTrace BPF program type implementation and sample use 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
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 [this message]
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 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=20190606205851.GI11035@oracle.com \
--to=kris.van.hees@oracle.com \
--cc=acme@kernel.org \
--cc=alexei.starovoitov@gmail.com \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=clm@fb.com \
--cc=daniel@iogearbox.net \
--cc=dtrace-devel@oss.oracle.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mhiramat@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.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).