Received: by 2002:a05:6a10:a0d1:0:0:0:0 with SMTP id j17csp494101pxa; Fri, 31 Jul 2020 18:48:26 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzn5Oghf4B9gv7tZcEbdtiN+E9XOrpbwK1fsi1zw3jgiUwd9tMw/VUCyKFrswPejKZwD05J X-Received: by 2002:a17:906:ca5a:: with SMTP id jx26mr6462124ejb.62.1596246506575; Fri, 31 Jul 2020 18:48:26 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1596246506; cv=none; d=google.com; s=arc-20160816; b=iBY6S1zyhsYbsEBAGTTfce//SulJFy30FflIUsOGVtAsQGQYyXVsknlc86o1zIfDop UyoL1hyKplG7ECkhqXYsCSqkQc5zVqQCWw0OXCQgbiET/1jAycrH10TixSHQScTJIpB+ aZF9LIMHQASBrbDw7ETkfvYtc6hktZC+3jBiH97EtlnnTlfOMm5ABmMByv3xCfPm4roA PV+3XsFULr9YoOe15RykPJoKaz4uzaNZ87HHlsJb1vn0dfiK37w9qyAhhALfpVXxkX0q JHU6UGmHNbwBw0dOjNLZCHgElEKYtVivlTbx5z0esNbEFJbYm1K9wJ31k3DHP5XV4S8w mMhA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=vJnx156cIb/ocnmEd5ytGaOA79Apq7RDxlvXJ4tSsU4=; b=iTkxMK/ErxGBjSXvSNP03VzAto9zsqVuEQQ26zrWeqFAXlfBuXBnwE6cZAG1UXyH65 pVbd7+6o+005JKungdONWjits4nl2rudFGHz615sQUAmxdCwVINlSRyNJO1UaEmLd4GM o91pwZYi2H4oaz72Lx73WPOU3+fhoMLtGOBMjn+o53kJ8KjcIpIMDbhSIL1kBexnmOev /iJQ049rR4S0oj32rkfAqIoMTMltaup6/Fb8dtDY4vLIzUitGgUHUGs3542yTUh+R2jG AKJcaDFhK6JcPkGNwu1Y9F+2af1aK82x4PwXKq7f7JxavfRw+jX8PKUoIss/q78zB8Zr 3ltw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=uHPJ8JTD; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id gu8si3044558ejb.317.2020.07.31.18.48.03; Fri, 31 Jul 2020 18:48:26 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=uHPJ8JTD; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728184AbgHABru (ORCPT + 99 others); Fri, 31 Jul 2020 21:47:50 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41894 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726794AbgHABru (ORCPT ); Fri, 31 Jul 2020 21:47:50 -0400 Received: from mail-wm1-x343.google.com (mail-wm1-x343.google.com [IPv6:2a00:1450:4864:20::343]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id BDB7AC06174A for ; Fri, 31 Jul 2020 18:47:49 -0700 (PDT) Received: by mail-wm1-x343.google.com with SMTP id c80so9880458wme.0 for ; Fri, 31 Jul 2020 18:47:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=vJnx156cIb/ocnmEd5ytGaOA79Apq7RDxlvXJ4tSsU4=; b=uHPJ8JTDI5M2xkK0OfVUZ91EQVxWN9DazwFxWTFkpAifi13mVt9bCnKisGvl27mBUC OvFoO0m9UX7sogSIhzYAPwMYSPIjRGt5zHfRme+S+/umFocYOjjZ6tvedl0AcH+sOl3z aKk7Lf0PwIXr/0Ko9KpWw/xp/82CeFEHrKHDiBfuQFzXZa4aYximl0LKOPKR0rJ+N9mR sDdNIsAXRz4PBBWeb4t+bU7xX1+0g8pDHK7nwycuN+CjwIsvIKZV71mQYKII4BhjYrZ1 Gm5IJPuhc7Hxx1eAmJvcYpBf9FSF3RLj/kkhrFfgu3pkBAKReMXgrG72QAixGcCBGWSz xIeg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=vJnx156cIb/ocnmEd5ytGaOA79Apq7RDxlvXJ4tSsU4=; b=chnumuma5boCMiZBJ31iRuxD32RxT04oOD/47Hln3INUZKGsqN+Mic1QNMsjK6C7vP fZzLPNvfU3llI/pkHNrxzw7rtZNU2LJ3zJy3hzKvCe+X0Hh/hjmKwhSIJ7VF0QXmguEq o2Ah3oL8pLchGYcHxH0jTSVpTtX0X5Im6vOBlhCtRLnoXJar+hrbTQ0yFgoPcwf9e9d0 pW27DfXrXTu4q1gkNXKwwIz3dbm217erQeEEPVc+LlJ2jqEIvUDcXz5I1qCuBim5XLHb SocXvqH0g1JB8JBYXrH4wjnYKjkfVfGyVsrVpNSX3ief4bT1knD2cq3mKbAPU72ahPsv rtLw== X-Gm-Message-State: AOAM532rtKMyVwPpxb0bIfdu9sBEmg1FNY3u12+ag8oMe3gf1ETQfiWE 8uPn+IWPRdHdxFMin79rSMOgZ9Uedn+S0n/chBTPTA== X-Received: by 2002:a1c:a9ce:: with SMTP id s197mr5914617wme.58.1596246468111; Fri, 31 Jul 2020 18:47:48 -0700 (PDT) MIME-Version: 1.0 References: <20200722054314.2103880-1-irogers@google.com> In-Reply-To: From: Ian Rogers Date: Fri, 31 Jul 2020 18:47:36 -0700 Message-ID: Subject: Re: [RFC PATCH] bpftool btf: Add prefix option to dump C To: Andrii Nakryiko Cc: Alexei Starovoitov , Daniel Borkmann , Martin KaFai Lau , Song Liu , Yonghong Song , Andrii Nakryiko , John Fastabend , KP Singh , Quentin Monnet , Jakub Kicinski , Jiri Olsa , =?UTF-8?B?VG9rZSBIw7hpbGFuZC1Kw7hyZ2Vuc2Vu?= , Networking , bpf , open list , Stanislav Fomichev Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jul 21, 2020 at 11:58 PM Andrii Nakryiko wrote: > > On Tue, Jul 21, 2020 at 10:44 PM Ian Rogers wrote: > > > > When bpftool dumps types and enum members into a header file for > > inclusion the names match those in the original source. If the same > > header file needs to be included in the original source and the bpf > > program, the names of structs, unions, typedefs and enum members will > > have naming collisions. > > vmlinux.h is not really intended to be used from user-space, because > it's incompatible with pretty much any other header that declares any > type. Ideally we should make this better, but that might require some > compiler support. We've been discussing with Yonghong extending Clang > with a compile-time check for whether some type is defined or not, > which would allow to guard every type and only declare it > conditionally, if it's missing. But that's just an idea at this point. Thanks Andrii! We're not looking at user-space code but the BPF code. The prefix idea comes from a way to solve this problem in C++ with namespaces: namespace vmlinux { #include "vmlinux.h" } As the BPF programs are C code then the prefix acts like the namespace. It seems strange to need to extend the language. > Regardless, vmlinux.h is also very much Clang-specific, and shouldn't > work well with GCC. Could you elaborate on the specifics of the use > case you have in mind? That could help me see what might be the right > solution. Thanks! So the use-case is similar to btf_iter.h: https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git/tree/tools/testing/selftests/bpf/progs/bpf_iter.h To avoid collisions with somewhat cleaner macro or not games. Prompted by your concern I was looking into changing bpf_iter.h to use a prefix to show what the difference would be like. I also think that there may be issues with our kernel and tool set up that may mean that the prefix is unnecessary, if I fix something else. Anyway, to give an example I needed to build the selftests but this is failing for me. What I see is: $ git clone git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git $ cd bpf-next $ make defconfig $ cat >>.config < > To avoid these collisions an approach is to redeclare the header file > > types and enum members, which leads to duplication and possible > > inconsistencies. Another approach is to use preprocessor macros > > to rename conflicting names, but this can be cumbersome if there are > > many conflicts. > > > > This patch adds a prefix option for the dumped names. Use of this option > > can avoid name conflicts and compile time errors. > > > > Signed-off-by: Ian Rogers > > --- > > .../bpf/bpftool/Documentation/bpftool-btf.rst | 7 ++++++- > > tools/bpf/bpftool/btf.c | 18 ++++++++++++++--- > > tools/lib/bpf/btf.h | 1 + > > tools/lib/bpf/btf_dump.c | 20 +++++++++++++------ > > 4 files changed, 36 insertions(+), 10 deletions(-) > > > > [...] > > > diff --git a/tools/lib/bpf/btf.h b/tools/lib/bpf/btf.h > > index 491c7b41ffdc..fea4baab00bd 100644 > > --- a/tools/lib/bpf/btf.h > > +++ b/tools/lib/bpf/btf.h > > @@ -117,6 +117,7 @@ struct btf_dump; > > > > struct btf_dump_opts { > > void *ctx; > > + const char *name_prefix; > > }; > > BTW, we can't do that, this breaks ABI. btf_dump_opts were added > before we understood the problem of backward/forward compatibility of > libbpf APIs, unfortunately. This could be fixed by adding a "new" API for the parameter, which would be unfortunate compared to just amending the existing API. There may be solutions that are less duplicative. Thanks, Ian > > > > typedef void (*btf_dump_printf_fn_t)(void *ctx, const char *fmt, va_list args); > > diff --git a/tools/lib/bpf/btf_dump.c b/tools/lib/bpf/btf_dump.c > > index e1c344504cae..baf2b4d82e1e 100644 > > --- a/tools/lib/bpf/btf_dump.c > > +++ b/tools/lib/bpf/btf_dump.c > > [...]