From: Steven Rostedt <rostedt@goodmis.org> To: Alexei Starovoitov <ast@plumgrid.com> Cc: Ingo Molnar <mingo@kernel.org>, Namhyung Kim <namhyung@kernel.org>, Arnaldo Carvalho de Melo <acme@infradead.org>, Jiri Olsa <jolsa@redhat.com>, Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>, Linux API <linux-api@vger.kernel.org>, Network Development <netdev@vger.kernel.org>, LKML <linux-kernel@vger.kernel.org>, Linus Torvalds <torvalds@linux-foundation.org> Subject: Re: [PATCH v3 linux-trace 4/8] samples: bpf: simple tracing example in C Date: Tue, 10 Feb 2015 07:24:12 -0500 [thread overview] Message-ID: <20150210072412.3ee73362@grimm.local.home> (raw) In-Reply-To: <CAMEtUuzon5LfG7PS9YmuW+0GzYMKehz1Ddk+6tXogZOZYdpb3g@mail.gmail.com> Added Linus because he's the one that would revert changes on breakage. On Mon, 9 Feb 2015 21:45:21 -0800 Alexei Starovoitov <ast@plumgrid.com> wrote: > On Mon, Feb 9, 2015 at 9:16 PM, Steven Rostedt <rostedt@goodmis.org> wrote: > > On Mon, 9 Feb 2015 23:08:36 -0500 > > Steven Rostedt <rostedt@goodmis.org> wrote: > > > >> I don't want to get stuck with pinned kernel data structures again. We > >> had 4 blank bytes of data for every event, because latency top hard > >> coded the field. Luckily, the 64 bit / 32 bit interface caused latency > >> top to have to use the event_parse code to work, and we were able to > >> remove that field after it was converted. > > I think your main point boils down to: > > > But I still do not want any hard coded event structures. All access to > > data from the binary code must be parsed by looking at the event/format > > files. Otherwise you will lock internals of the kernel as userspace > > ABI, because eBPF programs will break if those internals change, and > > that could severely limit progress in the future. > > and I completely agree. > > the patch 4 is an example. It doesn't mean in any way > that structs defined here is an ABI. > To be compatible across kernels the user space must read > format file as you mentioned in your other reply. The thing is, this is a sample. Which means it will be cut and pasted into other programs. If the sample does not follow the way we want users to use this, then how can we complain if they hard code it as well? > > > I'm wondering if we should label eBPF programs as "modules". That is, > > they have no guarantee of working from one kernel to the next. They > > execute in the kernel, thus they are very similar to modules. > > > > If we can get Linus to say that eBPF programs are not user space, and > > that they are treated the same as modules (no internal ABI), then I > > think we can be a bit more free at what we allow. > > I thought we already stated that. > Here is the quote from perf_event.h: > * # The RAW record below is opaque data wrt the ABI > * # > * # That is, the ABI doesn't make any promises wrt to > * # the stability of its content, it may vary depending > * # on event, hardware, kernel version and phase of > * # the moon. > * # > * # In other words, PERF_SAMPLE_RAW contents are not an ABI. > > and this example is reading PERF_SAMPLE_RAW events and > uses locally defined structs to print them for simplicity. As we found out the hard way with latencytop, comments like this does not matter. If an application does something like this, it's our fault if it breaks later. We can't say "hey you were suppose to do it this way". That argument breaks down even more if our own examples do not follow the way we want others to do things. -- Steve
WARNING: multiple messages have this Message-ID (diff)
From: Steven Rostedt <rostedt-nx8X9YLhiw1AfugRpC6u6w@public.gmane.org> To: Alexei Starovoitov <ast-uqk4Ao+rVK5Wk0Htik3J/w@public.gmane.org> Cc: Ingo Molnar <mingo-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>, Namhyung Kim <namhyung-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>, Arnaldo Carvalho de Melo <acme-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>, Jiri Olsa <jolsa-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>, Masami Hiramatsu <masami.hiramatsu.pt-FCd8Q96Dh0JBDgjK7y7TUQ@public.gmane.org>, Linux API <linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>, Network Development <netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>, LKML <linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>, Linus Torvalds <torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org> Subject: Re: [PATCH v3 linux-trace 4/8] samples: bpf: simple tracing example in C Date: Tue, 10 Feb 2015 07:24:12 -0500 [thread overview] Message-ID: <20150210072412.3ee73362@grimm.local.home> (raw) In-Reply-To: <CAMEtUuzon5LfG7PS9YmuW+0GzYMKehz1Ddk+6tXogZOZYdpb3g-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> Added Linus because he's the one that would revert changes on breakage. On Mon, 9 Feb 2015 21:45:21 -0800 Alexei Starovoitov <ast-uqk4Ao+rVK5Wk0Htik3J/w@public.gmane.org> wrote: > On Mon, Feb 9, 2015 at 9:16 PM, Steven Rostedt <rostedt-nx8X9YLhiw1AfugRpC6u6w@public.gmane.org> wrote: > > On Mon, 9 Feb 2015 23:08:36 -0500 > > Steven Rostedt <rostedt-nx8X9YLhiw1AfugRpC6u6w@public.gmane.org> wrote: > > > >> I don't want to get stuck with pinned kernel data structures again. We > >> had 4 blank bytes of data for every event, because latency top hard > >> coded the field. Luckily, the 64 bit / 32 bit interface caused latency > >> top to have to use the event_parse code to work, and we were able to > >> remove that field after it was converted. > > I think your main point boils down to: > > > But I still do not want any hard coded event structures. All access to > > data from the binary code must be parsed by looking at the event/format > > files. Otherwise you will lock internals of the kernel as userspace > > ABI, because eBPF programs will break if those internals change, and > > that could severely limit progress in the future. > > and I completely agree. > > the patch 4 is an example. It doesn't mean in any way > that structs defined here is an ABI. > To be compatible across kernels the user space must read > format file as you mentioned in your other reply. The thing is, this is a sample. Which means it will be cut and pasted into other programs. If the sample does not follow the way we want users to use this, then how can we complain if they hard code it as well? > > > I'm wondering if we should label eBPF programs as "modules". That is, > > they have no guarantee of working from one kernel to the next. They > > execute in the kernel, thus they are very similar to modules. > > > > If we can get Linus to say that eBPF programs are not user space, and > > that they are treated the same as modules (no internal ABI), then I > > think we can be a bit more free at what we allow. > > I thought we already stated that. > Here is the quote from perf_event.h: > * # The RAW record below is opaque data wrt the ABI > * # > * # That is, the ABI doesn't make any promises wrt to > * # the stability of its content, it may vary depending > * # on event, hardware, kernel version and phase of > * # the moon. > * # > * # In other words, PERF_SAMPLE_RAW contents are not an ABI. > > and this example is reading PERF_SAMPLE_RAW events and > uses locally defined structs to print them for simplicity. As we found out the hard way with latencytop, comments like this does not matter. If an application does something like this, it's our fault if it breaks later. We can't say "hey you were suppose to do it this way". That argument breaks down even more if our own examples do not follow the way we want others to do things. -- Steve
next prev parent reply other threads:[~2015-02-10 12:23 UTC|newest] Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top 2015-02-10 3:45 [PATCH v3 linux-trace 0/8] tracing: attach eBPF programs to tracepoints/syscalls/kprobe Alexei Starovoitov 2015-02-10 3:45 ` Alexei Starovoitov 2015-02-10 3:45 ` [PATCH v3 linux-trace 1/8] tracing: attach eBPF programs to tracepoints and syscalls Alexei Starovoitov 2015-02-10 3:45 ` Alexei Starovoitov 2015-02-10 4:46 ` Steven Rostedt 2015-02-10 4:46 ` Steven Rostedt 2015-02-10 5:13 ` Steven Rostedt 2015-02-10 5:13 ` Steven Rostedt 2015-02-10 3:45 ` [PATCH v3 linux-trace 2/8] tracing: allow eBPF programs to call ktime_get_ns() Alexei Starovoitov 2015-02-10 3:45 ` [PATCH v3 linux-trace 3/8] samples: bpf: simple tracing example in eBPF assembler Alexei Starovoitov 2015-02-10 3:45 ` [PATCH v3 linux-trace 4/8] samples: bpf: simple tracing example in C Alexei Starovoitov 2015-02-10 4:08 ` Steven Rostedt 2015-02-10 5:16 ` Steven Rostedt 2015-02-10 5:16 ` Steven Rostedt 2015-02-10 5:45 ` Alexei Starovoitov 2015-02-10 5:47 ` Alexei Starovoitov 2015-02-10 5:47 ` Alexei Starovoitov 2015-02-10 12:27 ` Steven Rostedt 2015-02-10 12:27 ` Steven Rostedt 2015-02-10 12:24 ` Steven Rostedt [this message] 2015-02-10 12:24 ` Steven Rostedt 2015-02-10 4:12 ` Steven Rostedt 2015-02-10 4:12 ` Steven Rostedt 2015-02-10 3:45 ` [PATCH v3 linux-trace 5/8] samples: bpf: counting example for kfree_skb tracepoint and write syscall Alexei Starovoitov 2015-02-10 3:45 ` Alexei Starovoitov 2015-02-10 3:45 ` [PATCH v3 linux-trace 6/8] samples: bpf: IO latency analysis (iosnoop/heatmap) Alexei Starovoitov 2015-02-10 3:46 ` [PATCH v3 linux-trace 7/8] tracing: attach eBPF programs to kprobe/kretprobe Alexei Starovoitov 2015-02-10 3:46 ` [PATCH v3 linux-trace 8/8] samples: bpf: simple kprobe example Alexei Starovoitov 2015-02-10 14:55 ` [PATCH v3 linux-trace 0/8] tracing: attach eBPF programs to tracepoints/syscalls/kprobe Steven Rostedt 2015-02-10 14:55 ` Steven Rostedt
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=20150210072412.3ee73362@grimm.local.home \ --to=rostedt@goodmis.org \ --cc=acme@infradead.org \ --cc=ast@plumgrid.com \ --cc=jolsa@redhat.com \ --cc=linux-api@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=masami.hiramatsu.pt@hitachi.com \ --cc=mingo@kernel.org \ --cc=namhyung@kernel.org \ --cc=netdev@vger.kernel.org \ --cc=torvalds@linux-foundation.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: linkBe 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.