From: Johannes Berg <johannes@sipsolutions.net>
To: Denis Kenzior <denkenz@gmail.com>, linux-wireless@vger.kernel.org
Subject: Re: [RESEND PATCH] nl80211: Allow GET_INTERFACE dumps to be filtered
Date: Fri, 12 Aug 2016 07:58:01 +0200 [thread overview]
Message-ID: <1470981481.26902.4.camel@sipsolutions.net> (raw)
In-Reply-To: <57ACC1F8.6070908@gmail.com> (sfid-20160811_202044_055484_513A0779)
On Thu, 2016-08-11 at 13:20 -0500, Denis Kenzior wrote:
> Hi Johannes,
>
> >> Speaking of indentation, can you point me to a doc of the rules I
> >
> > >
> > > should follow?
> >
> > You've seen Documentation/CodingStyle?
>
> Of course. But that one doesn't discuss that you want your function
> parameters to be aligned to the opening '('. Is there a dialect
> document specific to linux-wireless?
Sorry. I don't think this is specific to our part of the tree, and I'm
surprised it's not in there. But I see Arend also pointed you to
checkpatch.pl, which, I might add, you shouldn't always take as
authoritative since sometimes "fixing" things for it makes the code
look worse.
> The initial conditions are that:
> cb->args[0..2] == 0.
>
> So on the first iteration we set filter_wiphy == -1 and check the
> filter attributes. If set, we modify filter_wiphy accordingly.
>
> Even if filter_wiphy is set to 0, the if statement should still never
> be entered afterwards since wp_start and if_start are incremented.
>
> Is this what you're worried about? Do you see a fault in my logic?
No, I don't see a fault in the logic. I just think it's misleading. You
make the code look like it relies on filter_wiphy != 0, but then you go
and treat filter_wiphy==0 as a valid case.
In other places, like nl80211_prepare_wdev_dump(), we add 1 to the
wiphy and subtract it again later to avoid exactly this. Perhaps you
could do the same, and rely only on filter_wiphy instead of really
relying only on wp_start/if_start.
johannes
next prev parent reply other threads:[~2016-08-12 5:58 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-08-03 22:02 [RESEND PATCH] nl80211: Allow GET_INTERFACE dumps to be filtered Denis Kenzior
2016-08-11 12:47 ` Johannes Berg
2016-08-11 16:38 ` Denis Kenzior
2016-08-11 18:03 ` Johannes Berg
2016-08-11 18:20 ` Denis Kenzior
2016-08-11 18:58 ` Arend Van Spriel
2016-08-11 19:05 ` Denis Kenzior
2016-08-11 21:22 ` Arend Van Spriel
2016-08-12 5:58 ` Johannes Berg [this message]
2016-08-12 16:24 ` Denis Kenzior
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=1470981481.26902.4.camel@sipsolutions.net \
--to=johannes@sipsolutions.net \
--cc=denkenz@gmail.com \
--cc=linux-wireless@vger.kernel.org \
/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.