From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id CBA2DC74A35 for ; Wed, 10 Jul 2019 21:19:58 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id AC5B5208C4 for ; Wed, 10 Jul 2019 21:19:58 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727607AbfGJVTw (ORCPT ); Wed, 10 Jul 2019 17:19:52 -0400 Received: from www62.your-server.de ([213.133.104.62]:45558 "EHLO www62.your-server.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727220AbfGJVTw (ORCPT ); Wed, 10 Jul 2019 17:19:52 -0400 Received: from [78.46.172.2] (helo=sslproxy05.your-server.de) by www62.your-server.de with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89_1) (envelope-from ) id 1hlK08-0002zM-9q; Wed, 10 Jul 2019 23:19:44 +0200 Received: from [178.193.45.231] (helo=linux.home) by sslproxy05.your-server.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89) (envelope-from ) id 1hlK08-00021W-2p; Wed, 10 Jul 2019 23:19:44 +0200 Subject: Re: [PATCH V2 1/1 (was 0/1 by accident)] tools/dtrace: initial implementation of DTrace To: Jonathan Corbet Cc: Kris Van Hees , netdev@vger.kernel.org, bpf@vger.kernel.org, dtrace-devel@oss.oracle.com, linux-kernel@vger.kernel.org, rostedt@goodmis.org, mhiramat@kernel.org, acme@kernel.org, ast@kernel.org, Peter Zijlstra , Chris Mason , brendan.d.gregg@gmail.com, davem@davemloft.net References: <201907101537.x6AFboMR015946@aserv0122.oracle.com> <201907101542.x6AFgOO9012232@userv0121.oracle.com> <20190710181227.GA9925@oracle.com> <20190710143048.3923d1d9@lwn.net> From: Daniel Borkmann Message-ID: <1de27d29-65bb-89d3-9fca-7c452cd66934@iogearbox.net> Date: Wed, 10 Jul 2019 23:19:43 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <20190710143048.3923d1d9@lwn.net> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Authenticated-Sender: daniel@iogearbox.net X-Virus-Scanned: Clear (ClamAV 0.100.3/25506/Wed Jul 10 10:11:44 2019) Sender: bpf-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: bpf@vger.kernel.org On 07/10/2019 10:30 PM, Jonathan Corbet wrote: > On Wed, 10 Jul 2019 21:32:25 +0200 > Daniel Borkmann wrote: > >> Looks like you missed Brendan Gregg's prior feedback from v1 [0]. I haven't >> seen a strong compelling argument for why this needs to reside in the kernel >> tree given we also have all the other tracing tools and many of which also >> rely on BPF such as bcc, bpftrace, ply, systemtap, sysdig, lttng to just name >> a few. > > So I'm just watching from the sidelines here, but I do feel the need to > point out that Kris appears to be trying to follow the previous feedback > he got from Alexei, where creating tools/dtrace is exactly what he was > told to do: > > https://lwn.net/ml/netdev/20190521175617.ipry6ue7o24a2e6n@ast-mbp.dhcp.thefacebook.com/ > > Now he's being told the exact opposite. Not the best experience for > somebody who is trying to make the kernel better. Ugh, agree, sorry for the misleading direction. Alexei is currently offgrid this week, he might comment later. It has nothing to do with making the _kernel_ better, it's a /user space/ front end for the existing kernel infrastructure like many of the other tracers out there. Don't get me wrong, adding the missing /kernel parts/ for it is a totally different subject [and _that_ is what is making the kernel better, not the former]. Hypothetical question: does it make the _kernel_ better if we suddenly add a huge and complex project like tools/mysql/ to the kernel tree? Nope. > There are still people interested in DTrace out there. How would you > recommend that Kris proceed at this point? My recommendation to proceed is to maintain the dtrace user space tooling in its own separate project like the vast majority of all the other tracing projects (see also the other advantages that Steven pointed out from his experience), and extend the kernel bits whenever needed. Thanks, Daniel