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=-0.8 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS 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 6AD0CC352AA for ; Wed, 2 Oct 2019 16:56:05 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 41E3D21D81 for ; Wed, 2 Oct 2019 16:56:05 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="tXmz5bKB" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728062AbfJBQ4E (ORCPT ); Wed, 2 Oct 2019 12:56:04 -0400 Received: from mail-qk1-f194.google.com ([209.85.222.194]:40006 "EHLO mail-qk1-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725928AbfJBQ4E (ORCPT ); Wed, 2 Oct 2019 12:56:04 -0400 Received: by mail-qk1-f194.google.com with SMTP id y144so15685948qkb.7; Wed, 02 Oct 2019 09:56:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=OIrEl09ToJjHqpU/fbMoIlF4w9O4I9epnXRXCxHSJXM=; b=tXmz5bKBSc00vUbQztfRLEAKvUWd6F97z7tbFn99q/Rrx+R8lFDYZQVVJkbK1oD9yy exBxNZmz/0tH4YbDDCk2JiRsbwSJNnQn18LI2Cl9GQXEjDDoBjel5ce4eEBAizoDxQUz INJyCmKa7SqZrJP3iN6Hh7INojFifdkUDzDkxYxi/LlexqiFkPOrWQigCugKwYaPvYI4 xh1kuuC7oDIaPKtfw30w3YWIJmF3/RuvWUj8kNHKdLFE8GA4YAmv3c/JBJV1WnHLT3zx wnlYV6JnaYsAzXGwGXj4r2cY5hZKhzR0f/NeRqpfRVMdFXc2lWh4YLVf8OM5CrzQ57HX zIkQ== 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:content-transfer-encoding; bh=OIrEl09ToJjHqpU/fbMoIlF4w9O4I9epnXRXCxHSJXM=; b=KRPCv+EIqNt+fRl91rQlFlsTl7nODJL9fB4AKDX16BF781AJ5uiJ9bH/DZYckh1+xE bKO4uBu9CRirICsLhiBJpypH58gFQhLKJbxqCNbkVdbSf1WQqvhDogJs6oYOrviMAUVI LM+PgSkHMiEkTrZr9rFD92iZ+sSyApQGscAIAxOi6hJTmi0DpxTem+O7xCrz+d/1w9Of YswCbE2inneRBwWDjALTPzZvz8bTuaBU6m60KajDKWeFxfx5FoCexI175BhuLBTreL3X e+DwMHlL7/InndZWFu8JODWFUy5Gc8BqvRli53CUXzQL5y3MpZ9H8jjCztqJBXg7EeLP Detw== X-Gm-Message-State: APjAAAUzKzop2Nsx2/SRQX74EqIf1tFqHPH6XqL6OiGLyhhmyx5ZQSMV 2ou4lC1SbI6Q3u0g0EXWsW+C+37Zcy2CMUl30tM= X-Google-Smtp-Source: APXvYqxd1ktORxdnJwwg4BImPkehqyUedweYvhk7uiareg9EEVg4RjqZeDkV+a30ifztSTdpkINIVGqi9aldRksn7LU= X-Received: by 2002:a05:620a:119a:: with SMTP id b26mr4773459qkk.39.1570035363234; Wed, 02 Oct 2019 09:56:03 -0700 (PDT) MIME-Version: 1.0 References: <20190930164239.3697916-1-andriin@fb.com> <871rvwx3fg.fsf@toke.dk> <87lfu4t9up.fsf@toke.dk> <87imp7tz46.fsf@toke.dk> In-Reply-To: <87imp7tz46.fsf@toke.dk> From: Andrii Nakryiko Date: Wed, 2 Oct 2019 09:55:51 -0700 Message-ID: Subject: Re: [RFC][PATCH bpf-next] libbpf: add bpf_object__open_{file,mem} w/ sized opts To: =?UTF-8?B?VG9rZSBIw7hpbGFuZC1Kw7hyZ2Vuc2Vu?= Cc: Andrii Nakryiko , bpf , Networking , Alexei Starovoitov , Daniel Borkmann , KP Singh , Kernel Team Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Tue, Oct 1, 2019 at 11:56 PM Toke H=C3=B8iland-J=C3=B8rgensen wrote: > > Andrii Nakryiko writes: > > >> Sure, LGTM! Should we still keep the bit where it expands _opts in the > >> struct name as part of the macro, or does that become too obtuse? > > > > For me it's a question of code navigation. When I'll have a code > > > > LIBBPF_OPTS(bpf_object_open, ); > > > > I'll want to jump to the definition of "bpf_object_open" (e.g., w/ > > cscope)... and will find nothing, because it's actually > > bpf_object_open_opts. So I prefer user to spell it out exactly and in > > full, this is more maintainable in the long run, IMO. > > That's a good point; we shouldn't break cscope! > > BTW, speaking of cscope, how about having a 'make cscope' target for > libbpf to generate the definition file? :) I'm all for it, probably both `make cscope` and `make tags`, like Linux's make has? Feel free to add them, I can also replicate it to Github's Makefile after that. > > -Toke >