From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:59449) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rw97I-0003Sp-ML for qemu-devel@nongnu.org; Sat, 11 Feb 2012 04:19:37 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Rw97H-0001IW-7j for qemu-devel@nongnu.org; Sat, 11 Feb 2012 04:19:36 -0500 Received: from mail-iy0-f173.google.com ([209.85.210.173]:48791) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rw97H-0001IR-1U for qemu-devel@nongnu.org; Sat, 11 Feb 2012 04:19:35 -0500 Received: by iahk25 with SMTP id k25so1676361iah.4 for ; Sat, 11 Feb 2012 01:19:34 -0800 (PST) MIME-Version: 1.0 In-Reply-To: <4F329660.7040101@suse.de> References: <4F324A60.7070600@samsung.com> <4F326D66.6060808@suse.de> <4F329385.4030203@codemonkey.ws> <4F329660.7040101@suse.de> From: Blue Swirl Date: Sat, 11 Feb 2012 09:19:14 +0000 Message-ID: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] Restore consistent formatting List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: =?UTF-8?Q?Andreas_F=C3=A4rber?= Cc: Evgeny Voevodin , Stefan Hajnoczi , qemu-devel@nongnu.org, Dmitry Solodkiy On Wed, Feb 8, 2012 at 15:36, Andreas F=C3=A4rber wrote: > Am 08.02.2012 16:23, schrieb Anthony Liguori: >> On 02/08/2012 09:04 AM, malc wrote: >>> On Wed, 8 Feb 2012, Andreas F?rber wrote: >>> >>>> Arbitrarily reformatting your files is not okay. If you want a differe= nt >>>> formatting, you need to fix checkpatch.pl first to not error on that >>>> formatting in your files. >>> >>> It was always formatter like this (internally consistent), then others >>> added code which made it not so. >> >> We do have a mixed style in the audio layer. =C2=A0I'm not happy about t= hat >> but I also feel strongly that going through and doing a reformat is not >> a worthwhile exercise. >> >> I can also understand the desire to keep things consistent. =C2=A0But pa= tches >> should always go to the mailing list. =C2=A0I certainly would have acked= such >> a patch FWIW. >> >> I think people get a bit too excited about coding style. =C2=A0There are= much >> more important things to worry about in life than the number of spaces >> before a parenthesis :-) > > This is not about whether or not we put a space somewhere. > > It's about reviewers and SubmitAPatch telling people to run > checkpatch.pl on patches and checkpatch.pl reporting this as an ERROR, > not a WARNING. So if you follow Stefan's instructions on running the > script as a commit hook (which is the only sane way to run it when > handling lots of patches) you can't commit a patch or your local changes > when there are ERRORs. The warning levels are from Linux, they could well be incorrect. > I just spent half the night trying to find out why checkpatch.pl reports > CPUX86State *env, CPUYState *env, CPyState *env as ERRORs but not > CPUState *env. I did not succeed in really understanding it. Maybe the CPUState #defines in target-*/cpu.h confuse checkpatch. > So either we need to all stop using and telling to use checkpatch.pl or > someone needs to fix it. It's not that black or white. Obviously checkpatch.pl can make mistakes and some of its rules are actually not based on CODING_STYLE but they are in line with the current code (except for example in this audio case), so the output is usually helpful to make code more uniform. I wouldn't "fix" checkpatch to consider local style variations. If we don't want a rule that complains spaces after function identifiers, it could be removed entirely. Though then someone could submit patches to introduce them elsewhere, but if there is no rule, that should be OK. > Andreas > > -- > SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N=C3=BCrnberg, Germany > GF: Jeff Hawn, Jennifer Guild, Felix Imend=C3=B6rffer; HRB 16746 AG N=C3= =BCrnberg