From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753102AbbBJFPi (ORCPT ); Tue, 10 Feb 2015 00:15:38 -0500 Received: from cdptpa-outbound-snat.email.rr.com ([107.14.166.227]:34406 "EHLO cdptpa-oedge-vip.email.rr.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751228AbbBJFPg (ORCPT ); Tue, 10 Feb 2015 00:15:36 -0500 Date: Tue, 10 Feb 2015 00:16:08 -0500 From: Steven Rostedt To: Alexei Starovoitov Cc: Ingo Molnar , Namhyung Kim , Arnaldo Carvalho de Melo , Jiri Olsa , Masami Hiramatsu , linux-api@vger.kernel.org, netdev@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v3 linux-trace 4/8] samples: bpf: simple tracing example in C Message-ID: <20150210001608.157a9190@grimm.local.home> In-Reply-To: <20150209230836.7f913c60@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> X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.25; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-RR-Connecting-IP: 107.14.168.118:25 X-Cloudmark-Score: 0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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'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. -- Steve From mboxrd@z Thu Jan 1 00:00:00 1970 From: Steven Rostedt Subject: Re: [PATCH v3 linux-trace 4/8] samples: bpf: simple tracing example in C Date: Tue, 10 Feb 2015 00:16:08 -0500 Message-ID: <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> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Ingo Molnar , Namhyung Kim , Arnaldo Carvalho de Melo , Jiri Olsa , Masami Hiramatsu , linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Alexei Starovoitov Return-path: In-Reply-To: <20150209230836.7f913c60-2kNGR76GQU9OHLTnHDQRgA@public.gmane.org> Sender: linux-api-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org List-Id: netdev.vger.kernel.org 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'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. -- Steve