From: Jakub Kicinski <jakub.kicinski@netronome.com>
To: Stanislav Fomichev <sdf@fomichev.me>
Cc: netdev@vger.kernel.org, linux-kselftest@vger.kernel.org,
ast@kernel.org, daniel@iogearbox.net, shuah@kernel.org,
quentin.monnet@netronome.com, guro@fb.com,
jiong.wang@netronome.com, sdf@google.com,
bhole_prashant_q7@lab.ntt.co.jp, john.fastabend@gmail.com,
jbenc@redhat.com, treeze.taeung@gmail.com, yhs@fb.com,
osk@fb.com, sandipan@linux.vnet.ibm.com
Subject: Re: [PATCH v4 bpf-next 4/7] libbpf: add internal pin_name
Date: Thu, 8 Nov 2018 19:38:56 -0800 [thread overview]
Message-ID: <20181108193712.754659d7@cakuba.netronome.com> (raw)
In-Reply-To: <20181109002213.5914-5-s@fomichev.me>
On Thu, 8 Nov 2018 16:22:10 -0800, Stanislav Fomichev wrote:
> @@ -261,6 +266,18 @@ static void bpf_program__exit(struct bpf_program *prog)
> prog->idx = -1;
> }
>
> +static char *__bpf_program__pin_name(struct bpf_program *prog)
> +{
> + char *name;
> +
> + name = strdup(prog->section_name);
> + for (char *p = name; p && *p; p++)
Useful patch! I'm not sure about libbpf but in the kernel we don't do
C99 variable declarations inside for loop init. Perhaps better to stick
to kernel rules than invent our own.
Also, I'm tempted to say:
char *name, *p;
name = p = strdup(prog->section_name);
while ((p = strchr(p, '/')))
*p = '_';
;)
> + if (*p == '/')
> + *p = '_';
> +
> + return name;
> +}
WARNING: multiple messages have this Message-ID (diff)
From: jakub.kicinski at netronome.com (Jakub Kicinski)
Subject: [PATCH v4 bpf-next 4/7] libbpf: add internal pin_name
Date: Thu, 8 Nov 2018 19:38:56 -0800 [thread overview]
Message-ID: <20181108193712.754659d7@cakuba.netronome.com> (raw)
In-Reply-To: <20181109002213.5914-5-s@fomichev.me>
On Thu, 8 Nov 2018 16:22:10 -0800, Stanislav Fomichev wrote:
> @@ -261,6 +266,18 @@ static void bpf_program__exit(struct bpf_program *prog)
> prog->idx = -1;
> }
>
> +static char *__bpf_program__pin_name(struct bpf_program *prog)
> +{
> + char *name;
> +
> + name = strdup(prog->section_name);
> + for (char *p = name; p && *p; p++)
Useful patch! I'm not sure about libbpf but in the kernel we don't do
C99 variable declarations inside for loop init. Perhaps better to stick
to kernel rules than invent our own.
Also, I'm tempted to say:
char *name, *p;
name = p = strdup(prog->section_name);
while ((p = strchr(p, '/')))
*p = '_';
;)
> + if (*p == '/')
> + *p = '_';
> +
> + return name;
> +}
WARNING: multiple messages have this Message-ID (diff)
From: jakub.kicinski@netronome.com (Jakub Kicinski)
Subject: [PATCH v4 bpf-next 4/7] libbpf: add internal pin_name
Date: Thu, 8 Nov 2018 19:38:56 -0800 [thread overview]
Message-ID: <20181108193712.754659d7@cakuba.netronome.com> (raw)
Message-ID: <20181109033856.I94WdrkgPCxgwfy46GYq3jWIVVto_P-RJTDuUMwNFhs@z> (raw)
In-Reply-To: <20181109002213.5914-5-s@fomichev.me>
On Thu, 8 Nov 2018 16:22:10 -0800, Stanislav Fomichev wrote:
> @@ -261,6 +266,18 @@ static void bpf_program__exit(struct bpf_program *prog)
> prog->idx = -1;
> }
>
> +static char *__bpf_program__pin_name(struct bpf_program *prog)
> +{
> + char *name;
> +
> + name = strdup(prog->section_name);
> + for (char *p = name; p && *p; p++)
Useful patch! I'm not sure about libbpf but in the kernel we don't do
C99 variable declarations inside for loop init. Perhaps better to stick
to kernel rules than invent our own.
Also, I'm tempted to say:
char *name, *p;
name = p = strdup(prog->section_name);
while ((p = strchr(p, '/')))
*p = '_';
;)
> + if (*p == '/')
> + *p = '_';
> +
> + return name;
> +}
next prev parent reply other threads:[~2018-11-09 13:17 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-11-09 0:22 [PATCH v4 bpf-next 0/7] bpftool: support loading flow dissector Stanislav Fomichev
2018-11-09 0:22 ` Stanislav Fomichev
2018-11-09 0:22 ` sdf
2018-11-09 0:22 ` [PATCH v4 bpf-next 1/7] selftests/bpf: rename flow dissector section to flow_dissector Stanislav Fomichev
2018-11-09 0:22 ` Stanislav Fomichev
2018-11-09 0:22 ` sdf
2018-11-09 0:22 ` [PATCH v4 bpf-next 2/7] libbpf: cleanup after partial failure in bpf_object__pin Stanislav Fomichev
2018-11-09 0:22 ` Stanislav Fomichev
2018-11-09 0:22 ` sdf
2018-11-09 3:37 ` Jakub Kicinski
2018-11-09 3:37 ` Jakub Kicinski
2018-11-09 3:37 ` jakub.kicinski
2018-11-09 15:41 ` Stanislav Fomichev
2018-11-09 15:41 ` Stanislav Fomichev
2018-11-09 15:41 ` sdf
2018-11-09 0:22 ` [PATCH v4 bpf-next 3/7] libbpf: bpf_program__pin: add special case for instances.nr == 1 Stanislav Fomichev
2018-11-09 0:22 ` Stanislav Fomichev
2018-11-09 0:22 ` sdf
2018-11-09 0:22 ` [PATCH v4 bpf-next 4/7] libbpf: add internal pin_name Stanislav Fomichev
2018-11-09 0:22 ` Stanislav Fomichev
2018-11-09 0:22 ` sdf
2018-11-09 3:38 ` Jakub Kicinski [this message]
2018-11-09 3:38 ` Jakub Kicinski
2018-11-09 3:38 ` jakub.kicinski
2018-11-09 0:22 ` [PATCH v4 bpf-next 5/7] bpftool: add loadall command Stanislav Fomichev
2018-11-09 0:22 ` Stanislav Fomichev
2018-11-09 0:22 ` sdf
2018-11-09 3:41 ` Jakub Kicinski
2018-11-09 3:41 ` Jakub Kicinski
2018-11-09 3:41 ` jakub.kicinski
2018-11-09 13:29 ` Quentin Monnet
2018-11-09 13:29 ` Quentin Monnet
2018-11-09 13:29 ` quentin.monnet
2018-11-09 15:42 ` Stanislav Fomichev
2018-11-09 15:42 ` Stanislav Fomichev
2018-11-09 15:42 ` sdf
2018-11-09 0:22 ` [PATCH v4 bpf-next 6/7] bpftool: add pinmaps argument to the load/loadall Stanislav Fomichev
2018-11-09 0:22 ` Stanislav Fomichev
2018-11-09 0:22 ` sdf
2018-11-09 3:43 ` Jakub Kicinski
2018-11-09 3:43 ` Jakub Kicinski
2018-11-09 3:43 ` jakub.kicinski
2018-11-09 0:22 ` [PATCH v4 bpf-next 7/7] bpftool: support loading flow dissector Stanislav Fomichev
2018-11-09 0:22 ` Stanislav Fomichev
2018-11-09 0:22 ` sdf
2018-11-09 3:50 ` Jakub Kicinski
2018-11-09 3:50 ` Jakub Kicinski
2018-11-09 3:50 ` jakub.kicinski
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20181108193712.754659d7@cakuba.netronome.com \
--to=jakub.kicinski@netronome.com \
--cc=ast@kernel.org \
--cc=bhole_prashant_q7@lab.ntt.co.jp \
--cc=daniel@iogearbox.net \
--cc=guro@fb.com \
--cc=jbenc@redhat.com \
--cc=jiong.wang@netronome.com \
--cc=john.fastabend@gmail.com \
--cc=linux-kselftest@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=osk@fb.com \
--cc=quentin.monnet@netronome.com \
--cc=sandipan@linux.vnet.ibm.com \
--cc=sdf@fomichev.me \
--cc=sdf@google.com \
--cc=shuah@kernel.org \
--cc=treeze.taeung@gmail.com \
--cc=yhs@fb.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.