From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [GIT PULL] KVM updates for the 2.6.38 merge window Date: Tue, 11 Jan 2011 19:14:32 +0200 Message-ID: <4D2C8FF8.5060806@redhat.com> References: <4D2ACFA7.6000502@redhat.com> <4D2C21FE.3000406@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Marcelo Tosatti , linux-kernel , KVM list To: Linus Torvalds Return-path: In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org List-Id: kvm.vger.kernel.org On 01/11/2011 06:19 PM, Linus Torvalds wrote: > On Tue, Jan 11, 2011 at 1:25 AM, Avi Kivity wrote: >> What are your issues with the patch? > My issues are mainly two-fold: > > - I think "MINOR" is a totally idiotic and meaningless term. It has > no technical meaning. Why would IO be special? Is it because of > deadlock concerns with filesystem or block device layer locks? No. And > it clearly isn't about "sleeping", since a major fault can be > non-sleeping (think ramdisk, for example). > > Look at the other FAULT_FLAG_xyzzy flags. They have _hard_ > technical reasons. There's no ambiguity. And we ALREADY HAVE the one > that says "return if it would need to wait", and it's called > FAULT_FLAG_ALLOW_RETRY. > Okay; I'll drop that patch, and look at reusing the existing infrastructure. > The other issue is: > > - I wasn't aware of this, and clearly not enough other people were > either, or somebody would have told you that we already had people > working on the whole FAULT_FLAG_ALLOW_RETRY thing that is much fancier > and technically superior. > > So it simply boils down to the fact that I don't think > FAULT_FLAG_MAJOR was a good idea. It's badly done, is a total and > utter hack, and I don't see why I should ever merge it. And I'll improve the process on core patches as well.