All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@kernel.org>
To: Avi Kivity <avi@redhat.com>
Cc: Thomas Gleixner <tglx@linutronix.de>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	kvm@vger.kernel.org, Marcelo Tosatti <mtosatti@redhat.com>,
	Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
	x86@kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] kvm: optimize ISR lookups
Date: Wed, 23 May 2012 16:48:46 +0200	[thread overview]
Message-ID: <20120523144846.GA26974@gmail.com> (raw)
In-Reply-To: <4FBB6E8B.8020200@redhat.com>


* Avi Kivity <avi@redhat.com> wrote:

> On 05/22/2012 02:01 AM, Thomas Gleixner wrote:
> > > 
> > > Others are not my fault :)
> > > 
> > > Seriously, if Avi/Marcelo want to rewrite the ISR emulation
> >
> > Interesting POV, really.
> >
> > Did you ever notice that the kernel is a collaborative effort and not
> > controlled by "Avi/Marcelo"?
> >
> > Did you ever notice that arch/x86/kvm is part of arch/x86? 
> 
> This is silly.  Most of the time the kernel is advanced by 
> incremental patches.  Sometimes it is advanced by minor or 
> major refactoring.  It is never advanced by personal attacks 
> on contributors.

Thomas wasn't so much doing a personal attack, it was pointing 
out stupidity and then it was mocking the repeated stupidity. He 
very politely explained his point of view (with which I agree), 
and then you guys pressed the issue and there's just so many 
hours in the merge window, so you asked to be flamed ...

Avi, if you cannot be brought to properly reject incomplete 
patches going in the wrong direction then others maintainers 
interested in the code will do it.

If you start to consistently require from KVM contributors 
"incremental updates" in the right direction, not piling crap on 
crap, then such incidents won't happen. This isn't the first 
such incident but there's hope that it might be the last one.

The rule in arch/x86/ (and many other subsystems) is very 
simple: we don't speed up crappy code. If you want to speed it 
up then make it clean first, *then* is it suited for speedups. 
Crappy code is fragile and bound to introduce bugs, and crappy 
code leads to continued increased maintenance overhead, so 
crappy code is basically under a perpetual code freeze until 
it's uncrapped.

Thanks,

	Ingo

  reply	other threads:[~2012-05-23 14:48 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-05-21 16:37 [PATCH] kvm: optimize ISR lookups Michael S. Tsirkin
2012-05-21 18:44 ` Michael S. Tsirkin
2012-05-21 21:04 ` Thomas Gleixner
2012-05-21 21:51   ` Michael S. Tsirkin
2012-05-21 22:14     ` Thomas Gleixner
2012-05-21 22:24       ` Michael S. Tsirkin
2012-05-21 22:44         ` Thomas Gleixner
2012-05-21 22:50           ` Michael S. Tsirkin
2012-05-21 23:01         ` Thomas Gleixner
2012-05-22 10:46           ` Avi Kivity
2012-05-23 14:48             ` Ingo Molnar [this message]
2012-05-23 15:03               ` Avi Kivity
2012-05-23 20:10                 ` Thomas Gleixner
2012-05-23 20:46                   ` Michael S. Tsirkin
2012-05-23 23:02                     ` Thomas Gleixner
2012-05-23 15:14               ` Michael S. Tsirkin
2012-05-23 19:22                 ` H. Peter Anvin
2012-05-21 23:11         ` Thomas Gleixner
2012-05-21 23:06   ` Michael S. Tsirkin
2012-05-21 23:12     ` H. Peter Anvin
2012-05-21 23:36     ` Thomas Gleixner
2012-05-22 10:59   ` Avi Kivity
2012-05-22 17:26     ` Thomas Gleixner
2012-05-23 15:10       ` Avi Kivity
2012-05-23 18:37         ` Thomas Gleixner
2012-05-23 19:25           ` H. Peter Anvin
2012-05-23 22:00             ` Thomas Gleixner
2012-05-30 14:18               ` Avi Kivity

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=20120523144846.GA26974@gmail.com \
    --to=mingo@kernel.org \
    --cc=avi@redhat.com \
    --cc=hpa@zytor.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=mst@redhat.com \
    --cc=mtosatti@redhat.com \
    --cc=tglx@linutronix.de \
    --cc=x86@kernel.org \
    /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.