From: Dan Carpenter <dan.carpenter@oracle.com>
To: Kees Cook <keescook@chromium.org>
Cc: Len Baker <len.baker@gmx.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Michael Straube <straube.linux@gmail.com>,
Lee Jones <lee.jones@linaro.org>,
linux-staging@lists.linux.dev, linux-kernel@vger.kernel.org,
linux-hardening@vger.kernel.org
Subject: Re: [PATCH 1/2] staging/rtl8192u: Avoid CamelCase in names of variables
Date: Mon, 23 Aug 2021 11:54:56 +0300 [thread overview]
Message-ID: <20210823085455.GJ1931@kadam> (raw)
In-Reply-To: <202108220759.E6D94F75D@keescook>
On Sun, Aug 22, 2021 at 08:02:14AM -0700, Kees Cook wrote:
> On Sun, Aug 22, 2021 at 04:28:19PM +0200, Len Baker wrote:
> > Avoid CameCase in the names of all local variables inside the function
> > rtl8192_phy_SwChnlStepByStep().
>
> This mixes decamelization with some (minor) logic changes (moving
> initializations earlier). I'd normally do this kind of thing with a sed
> script and not touch anything else, so that the results can be compared
> against the sed command. And I'd include the sed command in the commit
> log.
Yep. Absolutely verboten on staging.
>
> I'm actually not sure what the norm is in the kernel for doing
> decamelization -- should the entire driver get decamelized at once,
> instead of just one function at a time? Greg, do you have an opinion
> here?
It doesn't matter. One function at a time is fine. So long as it's not
too long to review.
regards,
dan carpenter
next prev parent reply other threads:[~2021-08-23 8:55 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-08-22 14:28 [PATCH 0/2] staging/rtl8192u: Prefer kcalloc over open coded arithmetic Len Baker
2021-08-22 14:28 ` [PATCH 1/2] staging/rtl8192u: Avoid CamelCase in names of variables Len Baker
2021-08-22 15:02 ` Kees Cook
2021-08-23 8:54 ` Dan Carpenter [this message]
2021-08-22 14:28 ` [PATCH 2/2] staging/rtl8192u: Prefer kcalloc over open coded arithmetic Len Baker
2021-08-22 14:59 ` Kees Cook
2021-08-22 15:41 ` Len Baker
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=20210823085455.GJ1931@kadam \
--to=dan.carpenter@oracle.com \
--cc=gregkh@linuxfoundation.org \
--cc=keescook@chromium.org \
--cc=lee.jones@linaro.org \
--cc=len.baker@gmx.com \
--cc=linux-hardening@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-staging@lists.linux.dev \
--cc=straube.linux@gmail.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.