[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAEf4Bzb_49EvfBP0P-jo5=Rg9cP26_hSCztK4HcUMHD-4fPA=g@mail.gmail.com>
Date: Mon, 11 Nov 2019 18:11:21 -0800
From: Andrii Nakryiko <andrii.nakryiko@...il.com>
To: Jakub Kicinski <jakub.kicinski@...ronome.com>
Cc: Andrii Nakryiko <andriin@...com>, bpf <bpf@...r.kernel.org>,
Networking <netdev@...r.kernel.org>,
Alexei Starovoitov <ast@...com>,
Daniel Borkmann <daniel@...earbox.net>,
Kernel Team <kernel-team@...com>
Subject: Re: [PATCH v2 bpf-next 2/3] libbpf: make global data internal arrays
mmap()-able, if possible
On Mon, Nov 11, 2019 at 10:41 AM Jakub Kicinski
<jakub.kicinski@...ronome.com> wrote:
>
> On Sat, 9 Nov 2019 00:06:31 -0800, Andrii Nakryiko wrote:
> > +static int bpf_object__probe_array_mmap(struct bpf_object *obj)
> > +{
> > + struct bpf_create_map_attr attr = {
> > + .map_type = BPF_MAP_TYPE_ARRAY,
> > + .map_flags = BPF_F_MMAPABLE,
> > + .key_size = sizeof(int),
> > + .value_size = sizeof(int),
> > + .max_entries = 1,
> > + };
> > + int fd = bpf_create_map_xattr(&attr);
> > +
> > + if (fd >= 0) {
>
> The point of the empty line between variable declarations and code in
> the Linux coding style is to provide a visual separation between
> variables and code.
>
> If you call a complex function in variable init and then check for
> errors in the code that really breaks that principle.
I'll split declaration and initialization, no problem
>
> > + obj->caps.array_mmap = 1;
> > + close(fd);
> > + return 1;
> > + }
> > +
> > + return 0;
> > +}
>
Powered by blists - more mailing lists