From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jakub Kicinski Subject: Re: [PATCH bpf-next 0/5] Introduce libbpf_attach_type_by_name Date: Wed, 26 Sep 2018 16:20:07 -0700 Message-ID: <20180926162007.37a4b873@cakuba.netronome.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: , , , To: Andrey Ignatov Return-path: Received: from mail-qt1-f176.google.com ([209.85.160.176]:42014 "EHLO mail-qt1-f176.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726107AbeI0Ff3 (ORCPT ); Thu, 27 Sep 2018 01:35:29 -0400 Received: by mail-qt1-f176.google.com with SMTP id z8-v6so790374qto.9 for ; Wed, 26 Sep 2018 16:20:11 -0700 (PDT) In-Reply-To: Sender: netdev-owner@vger.kernel.org List-ID: On Wed, 26 Sep 2018 15:24:52 -0700, Andrey Ignatov wrote: > This patch set introduces libbpf_attach_type_by_name function in libbpf to > identify attach type by section name. > > This is useful to avoid writing same logic over and over again in user > space applications that leverage libbpf. > > Patch 1 has more details on the new function and problem being solved. > Patches 2 and 3 add support for new section names. > Patch 4 uses new function in a selftest. > Patch 5 adds selftest for libbpf_{prog,attach}_type_by_name. > > As a side note there are a lot of inconsistencies now between names used by > libbpf and bpftool (e.g. cgroup/skb vs cgroup_skb, cgroup_device and device > vs cgroup/dev, sockops vs sock_ops, etc). This patch set does not address > it but it tries not to make it harder to address it in the future. I was wondering a few times whether I should point it out to people during review, but thought it would be nit picking. Maybe we should be more strict. Your series LGTM!