[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20221102185230.27ce05b1@kernel.org>
Date: Wed, 2 Nov 2022 18:52:30 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: Jacob Keller <jacob.e.keller@...el.com>
Cc: <davem@...emloft.net>, <netdev@...r.kernel.org>,
<edumazet@...gle.com>, <pabeni@...hat.com>, <jiri@...nulli.us>,
<razor@...ckwall.org>, <nicolas.dichtel@...nd.com>,
<gnault@...hat.com>, <fw@...len.de>
Subject: Re: [PATCH net-next v2 01/13] genetlink: refactor the cmd <> policy
mapping dump
On Wed, 2 Nov 2022 16:52:21 -0700 Jacob Keller wrote:
> Does the change to ctx->opidx have any other side effects we care about?
> if not it might be more legible to write this as:
>
> /* don't modify ctx->opidx */
> }
>
> while (!ctx->single_op && ctx->opidx < genl_get_cmd_cnt(ctx->r)) {
>
>
> That makes the intent a bit more clear and shouldn't need a comment
> about entering the loop. It also means we don't need to modify
> ctx->opidx, though I'm not sure if those other side effects matter or
> not.. we were modifying it before..
>
> I don't know what else depends on the opidx.
I was just trying to make the patches slightly easier to read.
This chunk gets rewritten again in patch 10, and the opidx thing
is gone completely. I maintain a "keep dumping" boolean called
dump_map (because this code is dumping a mapping rather than
the policies which come later)
LMK if I should try harder to improve this patch or what patch 10
does makes this moot.
Powered by blists - more mailing lists