Received: by 2002:a25:86ce:0:0:0:0:0 with SMTP id y14csp1461019ybm; Tue, 21 May 2019 14:38:00 -0700 (PDT) X-Google-Smtp-Source: APXvYqxtaZndBi/ARngh/aVfV1YgYuAp//5B0XegIuD5N+Bq571lV8wrPLEMcqEDIGYdDZaP5gC5 X-Received: by 2002:a62:798b:: with SMTP id u133mr26646414pfc.210.1558474679936; Tue, 21 May 2019 14:37:59 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1558474679; cv=none; d=google.com; s=arc-20160816; b=Ydm32HP7kk1JDJBBhZ6SD2RgPUrv4p51FgpscOvYBukZFay0dm/5FRT6DpiCMvNL1p ERWy77qXJuw8yxXDJFRC4T/cueOL9Y1Bgu/G45kc/YflSqp17BoPgtDg1gqO0zSrQSKw eufCg1cdzyPOFj5DZjTIQQuMeMArqTKqilqUHVEVcIH6N3KH6yuYaFK64MYLtTHxSB2K Cwle+DHJNPDvhXOnAcRxtlm8wLHgkdqGLmlFRdDrH1j460lXQDT1txtqgAmGGpCZwKxX faJZAp4dh5Hsh8XpI2hPdzNh45JrVVQjOMcoyzUCI1F/h048IjHWt3Q1IMwGblPpJeje bu5A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date; bh=qyMUgmliyITIJg8ePsWFOu7MjZhOvhM0lF1q2SzSZ5o=; b=ubuwL/SvyUPl6TF860+ER0l2/FNzTjLK6f3zZjzrKJkve70uX5JaByLK1bZgOcvarq tvAxhbJOC/JhSH9f9sYJAKm0lScDBeD7ZT1a6xpsmIeS/dkvGZhFqDZ3XjcwJs9VrD0M W33xtr3GXRnJaDDJnS7Wzn2hrLXng/dsr3TUJefAvxf49SgsF0HgYXTg18vJ+tg6Rhls lWLVy5QCrowQf1pqGGc33WLz1QhUrp4xbpbx3P16np+qWNouhN4/864qjou2naNBQQWp F4rbJHAl2IHauKAoFt4uyBMk141jFRXWqcnHCU6oJ1oXEZflQeN0aUUJviJNvgRGT+Sj SCDQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id l133si19347983pga.556.2019.05.21.14.37.31; Tue, 21 May 2019 14:37:59 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727881AbfEUVgW (ORCPT + 99 others); Tue, 21 May 2019 17:36:22 -0400 Received: from mail.kernel.org ([198.145.29.99]:56740 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727222AbfEUVgV (ORCPT ); Tue, 21 May 2019 17:36:21 -0400 Received: from gandalf.local.home (cpe-66-24-58-225.stny.res.rr.com [66.24.58.225]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id EAFF82173E; Tue, 21 May 2019 21:36:19 +0000 (UTC) Date: Tue, 21 May 2019 17:36:18 -0400 From: Steven Rostedt To: Alexei Starovoitov Cc: Kris Van Hees , netdev@vger.kernel.org, bpf@vger.kernel.org, dtrace-devel@oss.oracle.com, linux-kernel@vger.kernel.org, mhiramat@kernel.org, acme@kernel.org, ast@kernel.org, daniel@iogearbox.net, peterz@infradead.org Subject: Re: [RFC PATCH 00/11] bpf, trace, dtrace: DTrace BPF program type implementation and sample use Message-ID: <20190521173618.2ebe8c1f@gandalf.local.home> In-Reply-To: <20190521205533.evfszcjvdouby7vp@ast-mbp.dhcp.thefacebook.com> References: <201905202347.x4KNl0cs030532@aserv0121.oracle.com> <20190521175617.ipry6ue7o24a2e6n@ast-mbp.dhcp.thefacebook.com> <20190521184137.GH2422@oracle.com> <20190521205533.evfszcjvdouby7vp@ast-mbp.dhcp.thefacebook.com> X-Mailer: Claws Mail 3.17.3 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 21 May 2019 13:55:34 -0700 Alexei Starovoitov wrote: > > The reasons for these patches is because I cannot do the same with the existing > > implementation. Yes, I can do some of it or use some workarounds to accomplish > > kind of the same thing, but at the expense of not being able to do what I need > > to do but rather do some kind of best effort alternative. That is not the goal > > here. > > what you call 'workaround' other people call 'feature'. > The kernel community doesn't accept extra code into the kernel > when user space can do the same. If that was really true, all file systems would be implemented on FUSE ;-) I was just at a technical conference that was not Linux focused, and I talked to a lot of admins that said they would love to have Dtrace scripts working on Linux unmodified. I need to start getting more familiar with the workings of eBPF and then look at what Dtrace has to see where something like this can be achieved, but right now just NACKing patches outright isn't being helpful. If you are not happy with this direction, I would love to see conversations where Kris shows you exactly what is required (from a feature perspective, not an implementation one) and we come up with a solution. -- Steve