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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id D5192C433EF for ; Thu, 10 Mar 2022 00:38:45 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238595AbiCJAjo (ORCPT ); Wed, 9 Mar 2022 19:39:44 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50380 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233452AbiCJAjn (ORCPT ); Wed, 9 Mar 2022 19:39:43 -0500 Received: from mail-il1-x134.google.com (mail-il1-x134.google.com [IPv6:2607:f8b0:4864:20::134]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id F2297117C90 for ; Wed, 9 Mar 2022 16:38:43 -0800 (PST) Received: by mail-il1-x134.google.com with SMTP id i1so2699329ila.7 for ; Wed, 09 Mar 2022 16:38:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=+AH1Ryok58z365yesvDKuxOdyN+Y3/Jp3lFo3kUZXrk=; b=XJUy0cc+kwqbriMvbKj+oIgRizvrFcTnKrbMHuv+sn/zgyBBdgDWiGhXmJcmXZ+jGx iJ98QiqWjmsdL18k7STO0UTPZoEYOEfysl7c5nZWiTu2ROIjBw9LKGS8lqJGyXrnWFlT qRzRTafhHUcpaZ4kgDw2rOJoGEiO1RBY/iXUoxq3o9MfTcUcasoOtRcl4BUEh+2gdUSz Hp/H5KsR5IhQz+cGCl3lgR3sJ/X4Oer2eZo2Beu7hO6PAj0uxm1EbtfD17wGNUw+4lXu 55X8TIaVPHZghQDzkTa+n+AEGY7f/+c15jGDFFQd0WbTvl9Uj+GZNNTOEXMEmFsyk0zY 8ytw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=+AH1Ryok58z365yesvDKuxOdyN+Y3/Jp3lFo3kUZXrk=; b=jp5+tZOayTSWHFww0ryBpVsV78Tx6V6TCPBhCPnRZT86Klou0DgSbCkZdcDiDaspEG Z7k+W+Pjb03dN87UiQpPB7Z3frUO2S22Bo2UjmOeS6x7HX4bfvKx0UjpBk53bkl7pFbd +BW4TLsb+FDaNUiYbze4loCwos2cfjoqWATHwC+CsY5TgLIp5JE5uqN5yDeKA4/k5LbD AI7zbZY32h5uowXdHhQiRtDOtTZ/Bi0CkLQu1LoCMCPx+7LagABLKxu6BnWEAE5mgHmo 40ZZ4rTQcNU6PJ2gA7S0tm7POZ/WMMXGC26tww+pa3ma0fsp+f/Wu66cqH1EICaXrtuI SNMQ== X-Gm-Message-State: AOAM532LM8Ns1MCHGFkpD/h7XDqrujvolg1wslACEjJkyThRga/iUy5s CjixmEBOwTS+Lo0TR8eWS5XbaFLRnFHEE1VEnRE= X-Google-Smtp-Source: ABdhPJx0EDBwsHEnAXkD/RuKm8RP/ZkmjpYOUDlRJ6Ui2+DmjTqYblivS2T5fuzfRo0c0jVlUQaCnyrFSESb4/J+B2o= X-Received: by 2002:a05:6e02:1a8e:b0:2c6:3b01:1ffe with SMTP id k14-20020a056e021a8e00b002c63b011ffemr1622216ilv.239.1646872723324; Wed, 09 Mar 2022 16:38:43 -0800 (PST) MIME-Version: 1.0 References: <9028e60f908d30d5f156064cebfd5af8d66c5c9c.camel@fb.com> <8d80bcf5802fc707e0f8a31812625d717f133300.camel@fb.com> In-Reply-To: <8d80bcf5802fc707e0f8a31812625d717f133300.camel@fb.com> From: Andrii Nakryiko Date: Wed, 9 Mar 2022 16:38:32 -0800 Message-ID: Subject: Re: [PATCH bpf-next 2/4] bpftool: add support for subskeletons To: Delyan Kratunov Cc: "daniel@iogearbox.net" , "ast@kernel.org" , "andrii@kernel.org" , "bpf@vger.kernel.org" Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: bpf@vger.kernel.org On Wed, Mar 9, 2022 at 4:10 PM Delyan Kratunov wrote: > > Sorry, missed this question originally. > > On Fri, 2022-03-04 at 11:29 -0800, Andrii Nakryiko wrote: > > Split BTF added on top makes it a bit more > > tolerable (though there is still a bunch of unnecessary complexity and > > overhead just for that pesky asterisk). > > > > Another alternative would be: > > > > typeof(char[123]) *my_ptr; > > > > This can be done without generating extra BTF. For complex types it's > > actually even easier to parse, tbh. I initially didn't like it, but > > now I'm thinking maybe for arrays and func_protos we should do just > > this? WDYT? > > typeof is _technically_ not standard C (I think it'll make it into C23). GCC and > Clang do both support it but I would guess we'd want the generated userspace > code to be compatible with as many toolchains and configurations as possible? > (e.g. people using c99 instead of gnu99) that ship has sailed, I'm afraid. btf.h and xsk.h (I'm not even talking about BPF-side headers) both use typeof() > > Beyond that, I feel that any complexity saved by the typeof is lost in special- > casing arrays and function prototypes when the current code is uniform across > all types. > > If you insist, I can go down this path but I'm not super enthusiastic about it > (and it's harder to read on top of everything). I can tell you are not :) I do think that typeof() makes it much easier to follow complicated cases. Just look at the example below: static int blah_fn(int x, int y) { return x + y; } struct S { typeof(char[24]) *my_ptr1; char (*my_ptr2)[24]; int (**my_func1)(int, int); typeof(int (*)(int, int)) *my_func2; }; int main() { static struct S s; char blah[24]; int (*fptr)(int, int); s.my_ptr1 = &blah; s.my_ptr2 = &blah; s.my_func1 = &fptr; s.my_func2 = &fptr; return 0; } Which one is easier to follow, my_ptr1 or my_ptr2? func pointer is a bit more hypothetical (hard to come up with realistic BPF program that would need func pointer type as global variable type), but I still did it for completeness. So it's not like I'm dead set against this split BTF approach, I just do really think that array variable case is better with typeof(). > > -- Delyan