mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@kernel.org>
To: "Wangnan (F)" <wangnan0@huawei.com>
Cc: He Kuang <hekuang@huawei.com>,
	ast@kernel.org, davem@davemloft.net, daniel@iogearbox.net,
	rostedt@goodmis.org, xiakaixu@huawei.com, ast@plumgrid.com,
	linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH] bpf: Add new bpf map type for timer
Date: Wed, 21 Oct 2015 12:47:08 +0200	[thread overview]
Message-ID: <20151021104708.GA16402@gmail.com> (raw)
In-Reply-To: <56276B22.4050402@huawei.com>


* Wangnan (F) <wangnan0@huawei.com> wrote:

> 
> 
> On 2015/10/21 18:20, Ingo Molnar wrote:
> >* He Kuang <hekuang@huawei.com> wrote:
> >
> >>ping and add ast@plumgrid.com, what's your opinion on this?
> >Firstly, two days isn't nearly enough for a 'review timeout', secondly, have you
> >seen the kbuild test reports?
> >
> >Thirdly, I suspect others will do a deeper review, but even stylistically the
> >patch is a bit weird, for example these kinds of unstructured struct initializers
> >are annoying:
> >
> >>>   struct bpf_map_def SEC("maps") timer_map = {
> >>>   	.type = BPF_MAP_TYPE_TIMER_ARRAY,
> >>>   	.key_size = sizeof(int),
> >>>   	.value_size = sizeof(unsigned long long),
> >>>   	.max_entries = 4,
> >>>   };
> >>>  	.map_alloc = fd_array_map_alloc,
> >>>  	.map_free = fd_array_map_free,
> >>>  	.map_get_next_key = array_map_get_next_key,
> >>>-	.map_lookup_elem = fd_array_map_lookup_elem,
> >>>+	.map_lookup_elem = empty_array_map_lookup_elem,
> >>>  	.map_update_elem = fd_array_map_update_elem,
> >>>  	.map_delete_elem = fd_array_map_delete_elem,
> >>>  	.map_fd_get_ptr = prog_fd_array_get_ptr,
> >>>@@ -312,7 +318,7 @@ static const struct bpf_map_ops perf_event_array_ops = {
> >>>  	.map_alloc = fd_array_map_alloc,
> >>>  	.map_free = perf_event_array_map_free,
> >>>  	.map_get_next_key = array_map_get_next_key,
> >>>-	.map_lookup_elem = fd_array_map_lookup_elem,
> >>>+	.map_lookup_elem = empty_array_map_lookup_elem,
> >>>  	.map_update_elem = fd_array_map_update_elem,
> >>>  	.map_delete_elem = fd_array_map_delete_elem,
> >>>  	.map_fd_get_ptr = perf_event_fd_array_get_ptr,
> >>>+static const struct bpf_map_ops timer_array_ops = {
> >>>+	.map_alloc = timer_array_map_alloc,
> >>>+	.map_free = timer_array_map_free,
> >>>+	.map_get_next_key = array_map_get_next_key,
> >>>+	.map_lookup_elem = empty_array_map_lookup_elem,
> >>>+	.map_update_elem = timer_array_map_update_elem,
> >>>+	.map_delete_elem = timer_array_map_delete_elem,
> >>>+};
> >>>+
> >>>+static struct bpf_map_type_list timer_array_type __read_mostly = {
> >>>+	.ops = &timer_array_ops,
> >>>+	.type = BPF_MAP_TYPE_TIMER_ARRAY,
> >>>+};
> >Please align initializations vertically, so the second column becomes readable,
> >patterns in them become easy to see and individual entries become easier to
> >compare.
> >
> >See for example kernel/sched/core.c:
> >
> >struct cgroup_subsys cpu_cgrp_subsys = {
> >         .css_alloc      = cpu_cgroup_css_alloc,
> >         .css_free       = cpu_cgroup_css_free,
> >         .css_online     = cpu_cgroup_css_online,
> >         .css_offline    = cpu_cgroup_css_offline,
> >         .fork           = cpu_cgroup_fork,
> >         .can_attach     = cpu_cgroup_can_attach,
> >         .attach         = cpu_cgroup_attach,
> >         .exit           = cpu_cgroup_exit,
> >         .legacy_cftypes = cpu_files,
> >         .early_init     = 1,
> >};
> >
> >That's a _lot_ more readable than:
> >
> >struct cgroup_subsys cpu_cgrp_subsys = {
> >         .css_alloc = cpu_cgroup_css_alloc,
> >         .css_free = cpu_cgroup_css_free,
> >         .css_online = cpu_cgroup_css_online,
> >         .css_offline = cpu_cgroup_css_offline,
> >         .fork = cpu_cgroup_fork,
> >         .can_attach = cpu_cgroup_attach,
> 
> Here :)
> 
> >         .attach = cpu_cgroup_attach,
> >         .exit = cpu_cgroup_exit,
> >         .legacy_cftypes = cpu_files,
> >         .early_init = 1,
> >};
> >
> >right? For example I've hidden a small initialization bug into the second variant,
> >how much time does it take for you to notice it?

Correct, so that was 18 minutes ;-)

The bug should be easier to ffind in this form:

struct cgroup_subsys cpu_cgrp_subsys = {
         .css_alloc      = cpu_cgroup_css_alloc,
         .css_free       = cpu_cgroup_css_free,
         .css_online     = cpu_cgroup_css_online,
         .css_offline    = cpu_cgroup_css_offline,
         .fork           = cpu_cgroup_fork,
         .can_attach     = cpu_cgroup_attach,
         .attach         = cpu_cgroup_attach,
         .exit           = cpu_cgroup_exit,
         .legacy_cftypes = cpu_files,
         .early_init     = 1,
};

as there's a visual anomaly at a glance already, if you look carefully enough.

Agreed? These kinds of visual clues get hidden if the vertical alignment is 
missing.

Thanks,

	Ingo

  reply	other threads:[~2015-10-21 10:47 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-10-19  5:34 He Kuang
2015-10-19  6:30 ` [RFC PATCH] bpf: bpf_timer_callback() can be static kbuild test robot
2015-10-19  6:30 ` [RFC PATCH] bpf: Add new bpf map type for timer kbuild test robot
2015-10-21 10:02 ` He Kuang
2015-10-21 10:20   ` Ingo Molnar
2015-10-21 10:38     ` Wangnan (F)
2015-10-21 10:47       ` Ingo Molnar [this message]
2015-10-21 19:53   ` Alexei Starovoitov

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=20151021104708.GA16402@gmail.com \
    --to=mingo@kernel.org \
    --cc=ast@kernel.org \
    --cc=ast@plumgrid.com \
    --cc=daniel@iogearbox.net \
    --cc=davem@davemloft.net \
    --cc=hekuang@huawei.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rostedt@goodmis.org \
    --cc=wangnan0@huawei.com \
    --cc=xiakaixu@huawei.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

Powered by JetHome