Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965119AbcCPAGK (ORCPT ); Tue, 15 Mar 2016 20:06:10 -0400 Received: from mail-io0-f170.google.com ([209.85.223.170]:36034 "EHLO mail-io0-f170.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751204AbcCPAGC (ORCPT ); Tue, 15 Mar 2016 20:06:02 -0400 MIME-Version: 1.0 In-Reply-To: <20160315235216.GI30721@dastard> References: <20160311223047.GZ30721@dastard> <20160312003556.GF32214@thunk.org> <20160313233049.GA30721@dastard> <56E69398.7030508@redhat.com> <20160314144603.GO29218@thunk.org> <20160315201431.GG30721@dastard> <20160315223313.GH30721@dastard> <20160315235216.GI30721@dastard> Date: Tue, 15 Mar 2016 17:06:00 -0700 X-Google-Sender-Auth: cPMttCBdR1m9n723f34d5wl2CNo Message-ID: Subject: Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks From: Linus Torvalds To: Dave Chinner Cc: "Theodore Ts'o" , Ric Wheeler , Andy Lutomirski , One Thousand Gnomes , Gregory Farnum , "Martin K. Petersen" , Christoph Hellwig , "Darrick J. Wong" , Jens Axboe , Andrew Morton , Linux API , Linux Kernel Mailing List , shane.seymour@hpe.com, Bruce Fields , linux-fsdevel , Jeff Layton , Eric Sandeen Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1816 Lines: 41 On Tue, Mar 15, 2016 at 4:52 PM, Dave Chinner wrote: > > It is pretty clear that the onus is on the patch submitter to > provide justification for inclusion, not for the reviewer/Maintainer > to have to prove that the solution is unworkable. I agree, but quite frankly, performance is a good justification. So if Ted can give performance numbers, that's justification enough. We've certainly taken changes with less. And with your "we should _not_ do this" argument, the onus is clearly on you. > "Google uses this" is not sufficient justification. Not per se, no, but it's a very traditional and time-honored model for "should we merge this". It's traditionally been things like "Redhat merged it in their distro kernel, because they have customers that want/need it". That is *the* reason many big projects got merged, ranging from filesystems to drivers etc. Take reiserfs, for example: it got merged because SuSE was actively using it. So "this feature is being used in real life" is a big hint that the standard upstream kernel may be missing something important. People arguing against things like that has been a big problem in the past. It took people _years_ to get over the whole Android thing. We need to merge stuff that people are using and depend on, because _not_ merging them just causes more and more distance between peoples kernels, and makes it even harder to merge in the future. I do agree that we want to have hard numbers. And I do think that we should strive for the whole "we want to merge" phase to be a time when we also look at "can we improve the interfaces". But that can - and often does - go too far. Again, we had _years_ of pointless masturbation over the whole Android thing, just because people were making up new interfaces. Linus