From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755336AbbBJFpp (ORCPT ); Tue, 10 Feb 2015 00:45:45 -0500 Received: from mail-qc0-f179.google.com ([209.85.216.179]:65455 "EHLO mail-qc0-f179.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751200AbbBJFpm (ORCPT ); Tue, 10 Feb 2015 00:45:42 -0500 MIME-Version: 1.0 In-Reply-To: <20150210001608.157a9190@grimm.local.home> References: <1423539961-21792-1-git-send-email-ast@plumgrid.com> <1423539961-21792-5-git-send-email-ast@plumgrid.com> <20150209230836.7f913c60@grimm.local.home> <20150210001608.157a9190@grimm.local.home> From: Alexei Starovoitov Date: Mon, 9 Feb 2015 21:45:21 -0800 Message-ID: Subject: Re: [PATCH v3 linux-trace 4/8] samples: bpf: simple tracing example in C To: Steven Rostedt Cc: Ingo Molnar , Namhyung Kim , Arnaldo Carvalho de Melo , Jiri Olsa , Masami Hiramatsu , Linux API , Network Development , LKML Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Feb 9, 2015 at 9:16 PM, Steven Rostedt wrote: > On Mon, 9 Feb 2015 23:08:36 -0500 > Steven Rostedt 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. > 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.