On 6 May 2014 19:59, Mike Day <ncm...@ncultra.org> wrote: > On Tue, May 6, 2014 at 2:28 PM, Peter Maydell <peter.mayd...@linaro.org> > 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