Received: by 2002:a05:7412:da14:b0:e2:908c:2ebd with SMTP id fe20csp2154945rdb; Mon, 9 Oct 2023 14:49:53 -0700 (PDT) X-Google-Smtp-Source: AGHT+IFeTePA339xBFD6KMmmw0EVB4E0ACurbBEqa5EM3QO8x/qQFUnZ1AIj/qbMu0vOS23TD3+g X-Received: by 2002:a17:90a:9481:b0:26b:6a2f:7d90 with SMTP id s1-20020a17090a948100b0026b6a2f7d90mr14678137pjo.23.1696888192767; Mon, 09 Oct 2023 14:49:52 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1696888192; cv=none; d=google.com; s=arc-20160816; b=eSF57Jms9/TfH7sNthJHtcGMSwD7dsQKLpolxpCeN9xVL6rNfqL0rjHmLcBrxDo5Ul Aft2jTJGzAHLa0KDYI3f2A5lV+7uh/flb0eyazZ/SkXjwQVTqWBkY9RAHOvmorB0VkXK ooYA6Aw+rrecAoE5x1Fa9oTiUCjr/e+hRzqpS8tC8ypwaT25Wbz12NjkBNlvb7ru9w5n Fn8tK0vLdFzDyRCE9jNmRNKiP7puLAQCc0GkS7iZiTgwDKikG57VQu2o4vS5qhdWDUhY qm9+8Pl/aPWKXieWwQfCc8hkQdpxWawWtT5+vm9BLxY6T+CxmUvbkdjziLkHPbaK6Zqt FcuA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date :dkim-signature; bh=E8jLa8WCVRYhNPNOsQGdeTW8m5b9AuJYLTqj3UKojyU=; fh=577r1dkCiZ4toM2POoqP3w5Qo/AaxEqqNrdETar0sVY=; b=ihmM5KJK2Z4YDAewQy7EjWXTrN5KU5Lh4XY+rCQYhoTBycTiEw4ZUXwMSjsw/cppiw RnSxSxrEhXXemuQ6q+FCSatoUWi2s9CyxIz81oFpex1OX1RtYm/uoCH+R2TAm/0jLAfj KARlDVHI1C+tZ5+etHYBaoX82p3DiYtHW1CzukAskVX2aEYAeRDCUeUrhIzkINVVRM12 hWXLBCkO9L9pkJGIdQt7dt5KH7QcKmthK+NjEtM3v81AXw246nP0T8glE1uMGb7rhAW+ DHLY1eLpKnvnCDZp13Mnc2LLA29FEpJOQXQiAQQHqulmcCbkJOnMUXHPQzdnC5Ld4ad1 FzKA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b="F/Xs7FkB"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.37 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from snail.vger.email (snail.vger.email. [23.128.96.37]) by mx.google.com with ESMTPS id q15-20020a17090a178f00b0027ce344c18asi391557pja.38.2023.10.09.14.49.52 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 09 Oct 2023 14:49:52 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.37 as permitted sender) client-ip=23.128.96.37; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b="F/Xs7FkB"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.37 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by snail.vger.email (Postfix) with ESMTP id 039C980E73DA; Mon, 9 Oct 2023 14:49:52 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at snail.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1378823AbjJIVts (ORCPT + 99 others); Mon, 9 Oct 2023 17:49:48 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35938 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1377858AbjJIVts (ORCPT ); Mon, 9 Oct 2023 17:49:48 -0400 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 857DD9D; Mon, 9 Oct 2023 14:49:46 -0700 (PDT) Received: by smtp.kernel.org (Postfix) with ESMTPSA id E2D3AC433C8; Mon, 9 Oct 2023 21:49:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1696888186; bh=/02JJBzcVaX1DU3waWXi0+UAJ2uTJXrVNatI5QxJLOI=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=F/Xs7FkBE1RhCI+yrZYDvbixH88IPAMRZuA5C5fHFjtdn6wM+kN3H5iHzyXLt5tlY RcpQYCPVhMiyUhYkik8kF4FdX14XbCdk8OL2JPKdPBiwWNwKAusqydF1Fj/CV/RzwX F+CmAH2GKYl3s0dh6iy/6zpPfvctGccx6P41mdC8glBfMPEzb7h91+REyXxUpjQTN/ 0Nnqs6Te0Fhxvfq1KKg13OnLJ+LShGJQPkCjB1TLfgyrT1rVioW43ZN/nYf75BGp+k 1avQBEtuCuA779PEPre7yuWs8DS5povIYfG9MToRHA4i+rL++p0I3u1+l8wLR0agsm 0PiNbzP+m4baw== Date: Mon, 9 Oct 2023 14:49:44 -0700 From: Jakub Kicinski To: Sean Christopherson , Linus Torvalds Cc: pbonzini@redhat.com, workflows@vger.kernel.org, linux-kernel@vger.kernel.org, kvm@vger.kernel.org Subject: Re: [PATCH] KVM: deprecate KVM_WERROR in favor of general WERROR Message-ID: <20231009144944.17c8eba3@kernel.org> In-Reply-To: References: <20231006205415.3501535-1-kuba@kernel.org> <20231009110613.2405ff47@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED, SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (snail.vger.email [0.0.0.0]); Mon, 09 Oct 2023 14:49:52 -0700 (PDT) On Mon, 9 Oct 2023 12:33:53 -0700 Sean Christopherson wrote: > > We do have sympathy for these folks, we are mostly volunteers after > > all. At the same time someone's under-investment should not be causing > > pain to those of us who _do_ build test stuff carefully. > > This is a bit over the top. Yeah, I need to add W=1 to my build scripts, but that's > not a lack of investment, just an oversight. Though in this case it likely wouldn't > have made any difference since Paolo grabbed the patches directly and might have > even bypassed linux-next. But again I would argue that's bad process, not a lack > of investment. If you do invest in build testing automation, why can't your automation count warnings rather than depend on WERROR? I don't understand. > > Rather than tweak stuff I'd prefer if we could agree that local -Werror > > is anti-social :( > > > > The global WERROR seems to be a good compromise. > > I disagree. WERROR simply doesn't provide the same coverage. E.g. it can't be > enabled for i386 without tuning FRAME_WARN, which (a) won't be at all obvious to > the average contributor and (b) increasing FRAME_WARN effectively reduces the > test coverage of KVM i386. > > For KVM x86, I want the rules for contributing to be clearly documented, and as > simple as possible. I don't see a sane way to achieve that with WERROR=y. Linus, you created the global WERROR option. Do you have an opinion on whether random subsystems should create their own WERROR flags? W=1 warning got in thru KVM and since they have a KVM_WERROR which defaults to enabled it broke build testing in networking. Randomly sprinkled -Werrors are fragile. Can we ask people to stop using them now that the global ERROR exists?