Re: Basic perf PMU support for Haswell v12

[Ingo Molnar]

* Andi Kleen <andi@xxxxxxxxxxxxxx> wrote:

> v12: Rebase to 3.10-rc2
> Add mem-loads/stores support for parity with Sandy Bridge.
> Fix fixed counters (Thanks Ingo!)
> Make late ack optional
> Export new config bits in sysfs.
> Minor changes

Sigh, what you have not fixed in your patches are the basic stylistic 
mistakes I pointed out to the past:

   https://lkml.org/lkml/2013/5/1/78

(my previous feedback is also quoted below.)

Here checkpatch.pl says this about your series:

  total: 6 errors, 10 warnings, 662 lines checked

and a handful of those checkpatch.pl complaints are for valid, real 
problems.

Furthermore, you have not replied to any of those two mails of mine, nor 
have you fixed the stylistic problems I pointed out, in these latest 
patches!

To fix it simply follow the advice I gave you twice before: run 
scripts/checkpatch.pl against your patches and address any valid 
complaints it gives _BEFORE YOU RESUBMIT THEM_!

Andi, what the heck is going on here? Your behavior makes no sense to me. 
You are pretty much the only contributor I know who makes a habit out of 
willfully ignoring maintainer feedback...

Thanks,

	Ingo

--------------------->
* Ingo Molnar <mingo@xxxxxxxxxx> wrote:

> 
> * Ingo Molnar <mingo@xxxxxxxxxx> wrote:
> 
> > 
> > * Ingo Molnar <mingo@xxxxxxxxxx> wrote:
> > 
> > > You say it's barebones, yet it does not work :-( How well was this 
> > > patch-set tested on non-Haswell hardware, which makes up 99.99% of our 
> > > installed base?
> > > 
> > > In particular, after applying your patches, 'perf top' stopped working 
> > > on an Intel testbox of mine:
> > 
> > The other problem I noticed was stylistic: when I applied your patches for 
> > testing even Git complained about their cleanliness ...
> > 
> > To quote from Documentation/SubmittingPatches:
> > 
> >   4) Style check your changes.
> > 
> >   Check your patch for basic style violations, details of which can be
> >   found in Documentation/CodingStyle.  Failure to do so simply wastes
> >   the reviewers time and will get your patch rejected, probably
> >   without even being read.
> > 
> >   At a minimum you should check your patches with the patch style
> >   checker prior to submission (scripts/checkpatch.pl).  You should
> >   be able to justify all violations that remain in your patch.
> > 
> > Please make your patches less sloppy!
> 
> Andi, you have not replied to this mail of mine.
> 
> What new measures are you taking to avoid such annoying stylistic problems 
> to creep into your patches?
> 
> These problems are regular in your patches and that has been going on for 
> years - causing maintenance overhead for many maintainers, not just me.
> 
> Apparently you are not using proper tooling (checkpatch.pl for example) to 
> check your patches. If you refuse to take action I will have to stop 
> dealing with your patches directly altogether - the overhead just does not 
> justify the effort. You'll need to get your patches reviewed by and signed 
> off by a more experienced kernel hacker who knows how to submit patches.
> 
> Thanks,
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/