Re: [Qemu-devel] [PATCH] Update QEMU checkpatch.pl to current linux version

[Peter Maydell]

On 6 May 2014 19:59, Mike Day <address@hidden> wrote:
> On Tue, May 6, 2014 at 2:28 PM, Peter Maydell <address@hidden> wrote:
>> A couple of ideas about how we could approach this:
>>  (1) make a commit which is simply copying the kernel's 0.32
>>       into our repo; then follow that with a series of commits which
>>       re-apply our local changes.
>>  (2) apply all the individual commits from the kernel between 0.31
>>      and 0.32 to our repo
>>  (3) give up and stick with 0.31...
>
> idea (1) makes perfect sense to me, and the local changes will be easy
> to review.
>
>> It might also be helpful if you could describe the benefits
>> we get from this update (any bugfixes for false positives we
>> tend to run into? useful new checks?)
>
> I think its a valid question whether to forward-port the Qemu checks
> to 0.32. I'm not sure, myself, but this gives folks an idea of what
> the cost/benefit is.

Well, some of our local checks we need, because our coding
style is not the same as the kernel's. In particular the brace
checks must be different.

> Yesterday I was bitten by the StudlyCaps syndrome in a patch I
> submitted which was checkpatch-clean. Afterward I noticed that version
> 0.31 has the check for StudlyCaps commented out. This is corrected in
> version 0.32 with a more ambitious check for "CamelCase."
>
> The CamelCase check in v0.32 tries to determine if the patch
> introduced StudlyCaps or if they already exist in the unpatched source
> file. (I was hoping for a three-line check I could paste into v0.31.)

If you want a camelcase check you'll need to fix it to enforce
QEMU's style requirements: struct, enum and function typenames
should be camelcase; scalar typenames and variable names not.
A quick scan of the code in this patch suggests it just rejects
all new camelcase names (I might well be misreading it, though.)

> I noticed some other new features - it uses an optional configuration
> file, checks for validly formed email addresses. The other changes I
> believe, are either experimental or providing tools for filtering or
> typing messages.

Nothing hugely important then, but if we're going to do
periodic updates it's probably going to be easier to do
them relatively frequently rather than every five years :-)

thanks
-- PMM