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.3 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,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 18926C2D0F3 for ; Wed, 1 Apr 2020 14:26:17 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id EE4632073B for ; Wed, 1 Apr 2020 14:26:16 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732992AbgDAO0Q (ORCPT ); Wed, 1 Apr 2020 10:26:16 -0400 Received: from dispatch1-us1.ppe-hosted.com ([67.231.154.164]:40508 "EHLO dispatch1-us1.ppe-hosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1732749AbgDAO0P (ORCPT ); Wed, 1 Apr 2020 10:26:15 -0400 Received: from mx1-us1.ppe-hosted.com (unknown [10.110.50.144]) by dispatch1-us1.ppe-hosted.com (PPE Hosted ESMTP Server) with ESMTP id B8F69200DB; Wed, 1 Apr 2020 14:26:14 +0000 (UTC) Received: from us4-mdac16-13.at1.mdlocal (unknown [10.110.49.195]) by mx1-us1.ppe-hosted.com (PPE Hosted ESMTP Server) with ESMTP id B748A800AF; Wed, 1 Apr 2020 14:26:14 +0000 (UTC) X-Virus-Scanned: Proofpoint Essentials engine Received: from mx1-us1.ppe-hosted.com (unknown [10.110.49.105]) by mx1-us1.ppe-hosted.com (PPE Hosted ESMTP Server) with ESMTPS id 559BB40073; Wed, 1 Apr 2020 14:26:14 +0000 (UTC) Received: from webmail.solarflare.com (uk.solarflare.com [193.34.186.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mx1-us1.ppe-hosted.com (PPE Hosted ESMTP Server) with ESMTPS id ED8349C007D; Wed, 1 Apr 2020 14:26:13 +0000 (UTC) Received: from [10.17.20.203] (10.17.20.203) by ukex01.SolarFlarecom.com (10.17.10.4) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Wed, 1 Apr 2020 15:26:07 +0100 Subject: Re: [PATCH v3 bpf-next 0/4] Add support for cgroup bpf_link To: Andrii Nakryiko CC: David Ahern , Alexei Starovoitov , Andrii Nakryiko , bpf , Networking , "Alexei Starovoitov" , Daniel Borkmann , "Andrey Ignatov" , Kernel Team References: <20200330030001.2312810-1-andriin@fb.com> <662788f9-0a53-72d4-2675-daec893b5b81@gmail.com> <20200331003222.gdc2qb5rmopphdxl@ast-mbp> <58cea4c7-e832-2632-7f69-5502b06310b2@gmail.com> <869adb74-5192-563d-0e8a-9cb578b2a601@solarflare.com> From: Edward Cree Message-ID: Date: Wed, 1 Apr 2020 15:26:04 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Content-Language: en-GB X-Originating-IP: [10.17.20.203] X-ClientProxiedBy: ocex03.SolarFlarecom.com (10.20.40.36) To ukex01.SolarFlarecom.com (10.17.10.4) X-TM-AS-Product-Ver: SMEX-12.5.0.1300-8.5.1020-25326.003 X-TM-AS-Result: No-9.170700-8.000000-10 X-TMASE-MatchedRID: csPTYAMX1+HecRzRckOs5/ZvT2zYoYOwt3aeg7g/usAM74Nf6tTB9sij F4UeOUZT7FsIwysVj2VO1SpuqMw3YVJAAk7j9W+XkJi1wdeHFtqcqlCdrhyhQCO7AnsM9hLAXa9 +3ZJzfMIWf1eVkaUg8CObEUW1s0wmEkhxDD0C3MwD2WXLXdz+AQZyESFXAljfSX8n1Gj4wAE/Fc xFvf6KLlTEG0VYp/krlVMZeeAkuNC/WXZS/HqJ2tAtbEEX0MxBxEHRux+uk8h+ICquNi0WJLCxA 2qCQxM8Ht6Glx7uLSICvd0lnWtVOMmLiOgEMwkoftwZ3X11IV0= X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No X-TMASE-Result: 10--9.170700-8.000000 X-TMASE-Version: SMEX-12.5.0.1300-8.5.1020-25326.003 X-MDID: 1585751174-9paET6OkOxIX Sender: bpf-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: bpf@vger.kernel.org On 01/04/2020 01:22, Andrii Nakryiko wrote: > Can you please point out where I was objecting to observability API > (which is LINK_QUERY thing we've discussed and I didn't oppose, and > I'm going to add next)? I didn't say you objected to it. I just said that you argued that it was OK for it to not land in the  same release as the rest of the API, because drgn could paper over  that gap.  Which seems to me to signify a dangerous way of thinking,  and I wanted to raise the alarm about that. (If you _don't_ see what's wrong with that argument... well, that'd  be even _more_ alarming.  Debuggers — and fuser, for that matter —  are for when things go wrong _in ways the designers of the system  failed to anticipate_.  They should not be part of a 'normal' work-  flow for dealing with problems that we already _know_ are possible;  it's kinda-sorta like how exceptions shouldn't be used for non-  exceptional situations.) -ed