From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id C66A9C77B61 for ; Thu, 27 Apr 2023 13:40:33 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S243587AbjD0Nkd (ORCPT ); Thu, 27 Apr 2023 09:40:33 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49756 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S243467AbjD0Nkb (ORCPT ); Thu, 27 Apr 2023 09:40:31 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5882644AE; Thu, 27 Apr 2023 06:40:25 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id E45CE611B3; Thu, 27 Apr 2023 13:40:24 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id DF907C433EF; Thu, 27 Apr 2023 13:40:19 +0000 (UTC) Date: Thu, 27 Apr 2023 14:40:16 +0100 From: Catalin Marinas To: Justin Forbes Cc: Andrew Morton , Mike Rapoport , Arnd Bergmann , Christophe Leroy , "David S. Miller" , Dinh Nguyen , Geert Uytterhoeven , Guo Ren , John Paul Adrian Glaubitz , "Kirill A. Shutemov" , Max Filippov , Michael Ellerman , Rich Felker , Russell King , Will Deacon , Yoshinori Sato , Zi Yan , linux-arm-kernel@lists.infradead.org, linux-csky@vger.kernel.org, linux-ia64@vger.kernel.org, linux-kernel@vger.kernel.org, linux-m68k@lists.linux-m68k.org, linux-mm@kvack.org, linux-sh@vger.kernel.org, linux-xtensa@linux-xtensa.org, linuxppc-dev@lists.ozlabs.org, sparclinux@vger.kernel.org Subject: Re: [PATCH v3 02/14] arm64: drop ranges in definition of ARCH_FORCE_MAX_ORDER Message-ID: References: <20230325060828.2662773-1-rppt@kernel.org> <20230325060828.2662773-3-rppt@kernel.org> <20230418150557.ea8c87c96ec64c899c88ab08@linux-foundation.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-csky@vger.kernel.org On Tue, Apr 25, 2023 at 11:09:58AM -0500, Justin Forbes wrote: > On Tue, Apr 18, 2023 at 5:22 PM Andrew Morton wrote: > > On Wed, 12 Apr 2023 18:27:08 +0100 Catalin Marinas wrote: > > > > It sounds nice in theory. In practice. EXPERT hides too much. When you > > > > flip expert, you expose over a 175ish new config options which are > > > > hidden behind EXPERT. You don't have to know what you are doing just > > > > with the MAX_ORDER, but a whole bunch more as well. If everyone were > > > > already running 10, this might be less of a problem. At least Fedora > > > > and RHEL are running 13 for 4K pages on aarch64. This was not some > > > > accidental choice, we had to carry a patch to even allow it for a > > > > while. If this does go in as is, we will likely just carry a patch to > > > > remove the "if EXPERT", but that is a bit of a disservice to users who > > > > might be trying to debug something else upstream, bisecting upstream > > > > kernels or testing a patch. In those cases, people tend to use > > > > pristine upstream sources without distro patches to verify, and they > > > > tend to use their existing configs. With this change, their MAX_ORDER > > > > will drop to 10 from 13 silently. That can look like a different > > > > issue enough to ruin a bisect or have them give bad feedback on a > > > > patch because it introduces a "regression" which is not a regression > > > > at all, but a config change they couldn't see. > > > > > > If we remove EXPERT (as prior to this patch), I'd rather keep the ranges > > > and avoid having to explain to people why some random MAX_ORDER doesn't > > > build (keeping the range would also make sense for randconfig, not sure > > > we got to any conclusion there). > > > > Well this doesn't seem to have got anywhere. I think I'll send the > > patchset into Linus for the next merge window as-is. Please let's take > > a look at this Kconfig presentation issue during the following -rc > > cycle. > > Well, I am very sorry to see this going in as is. It will silently > change people building with oldconfig, and anyone not paying attention > will not notice until an issue is hit where "it worked before, and my > config hasn't changed". If EXPERT is unset, there is no notification, > just a changed behavior. While it would be easy for me to carry a > patch dropping the if EXPERT, it will not help any users building on > upstream with our configs, whether for their own regular use, or while > trying to debug other issues, I expect it will result in a reasonable > amount of frustration from users trying to do the right thing and > bisect or test patches upstream. As I said in a previous reply, I'm fine with reverting this commit if it breaks existing configs. It's only that Andrew had already queued it in his tree but we have time until the final 6.4 kernel is released. That said, would you mind sending a patch reverting it (if removing EXPERT, I'd like to keep the ranges)? ;) Thanks. -- Catalin From mboxrd@z Thu Jan 1 00:00:00 1970 From: Catalin Marinas Date: Thu, 27 Apr 2023 13:40:16 +0000 Subject: Re: [PATCH v3 02/14] arm64: drop ranges in definition of ARCH_FORCE_MAX_ORDER Message-Id: List-Id: References: <20230325060828.2662773-1-rppt@kernel.org> <20230325060828.2662773-3-rppt@kernel.org> <20230418150557.ea8c87c96ec64c899c88ab08@linux-foundation.org> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable To: Justin Forbes Cc: Andrew Morton , Mike Rapoport , Arnd Bergmann , Christophe Leroy , "David S. Miller" , Dinh Nguyen , Geert Uytterhoeven , Guo Ren , John Paul Adrian Glaubitz , "Kirill A. Shutemov" , Max Filippov , Michael Ellerman , Rich Felker , Russell King , Will Deacon , Yoshinori Sato , Zi Yan , linux-arm-kernel@lists.infradead.org, linux-csky@vger.kernel.org, linux-ia64@vger.kernel.org, linux-kernel@vger.kernel.org, linux-m68k@lists.linux-m68k.org, linux-mm@kvack.org, linux-sh@vger.kernel.org, linux-xtensa@linux-xtensa.org, linuxppc-dev@lists.ozlabs.org, sparclinux@vger.kernel.org On Tue, Apr 25, 2023 at 11:09:58AM -0500, Justin Forbes wrote: > On Tue, Apr 18, 2023 at 5:22=E2=80=AFPM Andrew Morton wrote: > > On Wed, 12 Apr 2023 18:27:08 +0100 Catalin Marinas wrote: > > > > It sounds nice in theory. In practice. EXPERT hides too much. When = you > > > > flip expert, you expose over a 175ish new config options which are > > > > hidden behind EXPERT. You don't have to know what you are doing ju= st > > > > with the MAX_ORDER, but a whole bunch more as well. If everyone we= re > > > > already running 10, this might be less of a problem. At least Fedora > > > > and RHEL are running 13 for 4K pages on aarch64. This was not some > > > > accidental choice, we had to carry a patch to even allow it for a > > > > while. If this does go in as is, we will likely just carry a patch= to > > > > remove the "if EXPERT", but that is a bit of a disservice to users = who > > > > might be trying to debug something else upstream, bisecting upstream > > > > kernels or testing a patch. In those cases, people tend to use > > > > pristine upstream sources without distro patches to verify, and they > > > > tend to use their existing configs. With this change, their MAX_ORD= ER > > > > will drop to 10 from 13 silently. That can look like a different > > > > issue enough to ruin a bisect or have them give bad feedback on a > > > > patch because it introduces a "regression" which is not a regression > > > > at all, but a config change they couldn't see. > > > > > > If we remove EXPERT (as prior to this patch), I'd rather keep the ran= ges > > > and avoid having to explain to people why some random MAX_ORDER doesn= 't > > > build (keeping the range would also make sense for randconfig, not su= re > > > we got to any conclusion there). > > > > Well this doesn't seem to have got anywhere. I think I'll send the > > patchset into Linus for the next merge window as-is. Please let's take > > a look at this Kconfig presentation issue during the following -rc > > cycle. >=20 > Well, I am very sorry to see this going in as is. It will silently > change people building with oldconfig, and anyone not paying attention > will not notice until an issue is hit where "it worked before, and my > config hasn't changed". If EXPERT is unset, there is no notification, > just a changed behavior. While it would be easy for me to carry a > patch dropping the if EXPERT, it will not help any users building on > upstream with our configs, whether for their own regular use, or while > trying to debug other issues, I expect it will result in a reasonable > amount of frustration from users trying to do the right thing and > bisect or test patches upstream. As I said in a previous reply, I'm fine with reverting this commit if it breaks existing configs. It's only that Andrew had already queued it in his tree but we have time until the final 6.4 kernel is released. That said, would you mind sending a patch reverting it (if removing EXPERT, I'd like to keep the ranges)? ;) Thanks. --=20 Catalin From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from lists.ozlabs.org (lists.ozlabs.org [112.213.38.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id D855BC77B61 for ; Thu, 27 Apr 2023 13:41:01 +0000 (UTC) Received: from boromir.ozlabs.org (localhost [IPv6:::1]) by lists.ozlabs.org (Postfix) with ESMTP id 4Q6cMJ1W0qz3fVL for ; Thu, 27 Apr 2023 23:41:00 +1000 (AEST) Authentication-Results: lists.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=kernel.org (client-ip=2604:1380:4641:c500::1; helo=dfw.source.kernel.org; envelope-from=cmarinas@kernel.org; receiver=) Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 4Q6cLh5ntQz3cGV for ; Thu, 27 Apr 2023 23:40:28 +1000 (AEST) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id D2E7A6195F; Thu, 27 Apr 2023 13:40:24 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id DF907C433EF; Thu, 27 Apr 2023 13:40:19 +0000 (UTC) Date: Thu, 27 Apr 2023 14:40:16 +0100 From: Catalin Marinas To: Justin Forbes Subject: Re: [PATCH v3 02/14] arm64: drop ranges in definition of ARCH_FORCE_MAX_ORDER Message-ID: References: <20230325060828.2662773-1-rppt@kernel.org> <20230325060828.2662773-3-rppt@kernel.org> <20230418150557.ea8c87c96ec64c899c88ab08@linux-foundation.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Rich Felker , linux-ia64@vger.kernel.org, linux-sh@vger.kernel.org, Max Filippov , Guo Ren , linux-csky@vger.kernel.org, sparclinux@vger.kernel.org, Will Deacon , Yoshinori Sato , Russell King , Geert Uytterhoeven , Zi Yan , linux-xtensa@linux-xtensa.org, Arnd Bergmann , linux-m68k@lists.linux-m68k.org, John Paul Adrian Glaubitz , linux-arm-kernel@lists.infradead.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Dinh Nguyen , Mike Rapoport , Andrew Morton , linuxppc-dev@lists.ozlabs.org, "David S. Miller" , "Kirill A. Shutemov" Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" On Tue, Apr 25, 2023 at 11:09:58AM -0500, Justin Forbes wrote: > On Tue, Apr 18, 2023 at 5:22 PM Andrew Morton wrote: > > On Wed, 12 Apr 2023 18:27:08 +0100 Catalin Marinas wrote: > > > > It sounds nice in theory. In practice. EXPERT hides too much. When you > > > > flip expert, you expose over a 175ish new config options which are > > > > hidden behind EXPERT. You don't have to know what you are doing just > > > > with the MAX_ORDER, but a whole bunch more as well. If everyone were > > > > already running 10, this might be less of a problem. At least Fedora > > > > and RHEL are running 13 for 4K pages on aarch64. This was not some > > > > accidental choice, we had to carry a patch to even allow it for a > > > > while. If this does go in as is, we will likely just carry a patch to > > > > remove the "if EXPERT", but that is a bit of a disservice to users who > > > > might be trying to debug something else upstream, bisecting upstream > > > > kernels or testing a patch. In those cases, people tend to use > > > > pristine upstream sources without distro patches to verify, and they > > > > tend to use their existing configs. With this change, their MAX_ORDER > > > > will drop to 10 from 13 silently. That can look like a different > > > > issue enough to ruin a bisect or have them give bad feedback on a > > > > patch because it introduces a "regression" which is not a regression > > > > at all, but a config change they couldn't see. > > > > > > If we remove EXPERT (as prior to this patch), I'd rather keep the ranges > > > and avoid having to explain to people why some random MAX_ORDER doesn't > > > build (keeping the range would also make sense for randconfig, not sure > > > we got to any conclusion there). > > > > Well this doesn't seem to have got anywhere. I think I'll send the > > patchset into Linus for the next merge window as-is. Please let's take > > a look at this Kconfig presentation issue during the following -rc > > cycle. > > Well, I am very sorry to see this going in as is. It will silently > change people building with oldconfig, and anyone not paying attention > will not notice until an issue is hit where "it worked before, and my > config hasn't changed". If EXPERT is unset, there is no notification, > just a changed behavior. While it would be easy for me to carry a > patch dropping the if EXPERT, it will not help any users building on > upstream with our configs, whether for their own regular use, or while > trying to debug other issues, I expect it will result in a reasonable > amount of frustration from users trying to do the right thing and > bisect or test patches upstream. As I said in a previous reply, I'm fine with reverting this commit if it breaks existing configs. It's only that Andrew had already queued it in his tree but we have time until the final 6.4 kernel is released. That said, would you mind sending a patch reverting it (if removing EXPERT, I'd like to keep the ranges)? ;) Thanks. -- Catalin From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id F20A7C77B61 for ; Thu, 27 Apr 2023 13:41:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=VBOiTQ3P8LakJsG4ovooUmBF6LJNErVul/P297av5tk=; b=mgNKxxc33Xbiev CRLEOQPFOTqjZe3tX5tIK0rLB4idP1l/FjCggT8gkUE9dy4el8qD7P1VDCTqLMekL4Ykn1psgwQ91 cW9evmEz2WHNRVDUjYjE18ESiLEJhefXvNMtURUF9vzJIRn+b1knm3VKF4LKeHWxIOdNODeHJzINb B/9+AGx56shAxpacv2e6UwEUdTZ3TOOpSqVbhmVue6PTjwtyavbdwRTonkpypa6j4ptDWHM8dUaTM hmgZ9v26m1GPyZ7CSYbVT//w1Xbm5HWUPgIYHHdxSxQnpLbhtGL4kBFYPe2j4GjASD4mQb9y+lER5 oHfv8uscmK5tahbsye9w==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1ps1rL-006fWe-1C; Thu, 27 Apr 2023 13:40:31 +0000 Received: from dfw.source.kernel.org ([139.178.84.217]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1ps1rI-006fW9-0M for linux-arm-kernel@lists.infradead.org; Thu, 27 Apr 2023 13:40:29 +0000 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id D2E7A6195F; Thu, 27 Apr 2023 13:40:24 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id DF907C433EF; Thu, 27 Apr 2023 13:40:19 +0000 (UTC) Date: Thu, 27 Apr 2023 14:40:16 +0100 From: Catalin Marinas To: Justin Forbes Cc: Andrew Morton , Mike Rapoport , Arnd Bergmann , Christophe Leroy , "David S. Miller" , Dinh Nguyen , Geert Uytterhoeven , Guo Ren , John Paul Adrian Glaubitz , "Kirill A. Shutemov" , Max Filippov , Michael Ellerman , Rich Felker , Russell King , Will Deacon , Yoshinori Sato , Zi Yan , linux-arm-kernel@lists.infradead.org, linux-csky@vger.kernel.org, linux-ia64@vger.kernel.org, linux-kernel@vger.kernel.org, linux-m68k@lists.linux-m68k.org, linux-mm@kvack.org, linux-sh@vger.kernel.org, linux-xtensa@linux-xtensa.org, linuxppc-dev@lists.ozlabs.org, sparclinux@vger.kernel.org Subject: Re: [PATCH v3 02/14] arm64: drop ranges in definition of ARCH_FORCE_MAX_ORDER Message-ID: References: <20230325060828.2662773-1-rppt@kernel.org> <20230325060828.2662773-3-rppt@kernel.org> <20230418150557.ea8c87c96ec64c899c88ab08@linux-foundation.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230427_064028_251396_04176149 X-CRM114-Status: GOOD ( 41.56 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org T24gVHVlLCBBcHIgMjUsIDIwMjMgYXQgMTE6MDk6NThBTSAtMDUwMCwgSnVzdGluIEZvcmJlcyB3 cm90ZToKPiBPbiBUdWUsIEFwciAxOCwgMjAyMyBhdCA1OjIy4oCvUE0gQW5kcmV3IE1vcnRvbiA8 YWtwbUBsaW51eC1mb3VuZGF0aW9uLm9yZz4gd3JvdGU6Cj4gPiBPbiBXZWQsIDEyIEFwciAyMDIz IDE4OjI3OjA4ICswMTAwIENhdGFsaW4gTWFyaW5hcyA8Y2F0YWxpbi5tYXJpbmFzQGFybS5jb20+ IHdyb3RlOgo+ID4gPiA+IEl0IHNvdW5kcyBuaWNlIGluIHRoZW9yeS4gSW4gcHJhY3RpY2UuIEVY UEVSVCBoaWRlcyB0b28gbXVjaC4gV2hlbiB5b3UKPiA+ID4gPiBmbGlwIGV4cGVydCwgeW91IGV4 cG9zZSBvdmVyIGEgMTc1aXNoIG5ldyBjb25maWcgb3B0aW9ucyB3aGljaCBhcmUKPiA+ID4gPiBo aWRkZW4gYmVoaW5kIEVYUEVSVC4gIFlvdSBkb24ndCBoYXZlIHRvIGtub3cgd2hhdCB5b3UgYXJl IGRvaW5nIGp1c3QKPiA+ID4gPiB3aXRoIHRoZSBNQVhfT1JERVIsIGJ1dCBhIHdob2xlIGJ1bmNo IG1vcmUgYXMgd2VsbC4gIElmIGV2ZXJ5b25lIHdlcmUKPiA+ID4gPiBhbHJlYWR5IHJ1bm5pbmcg MTAsIHRoaXMgbWlnaHQgYmUgbGVzcyBvZiBhIHByb2JsZW0uIEF0IGxlYXN0IEZlZG9yYQo+ID4g PiA+IGFuZCBSSEVMIGFyZSBydW5uaW5nIDEzIGZvciA0SyBwYWdlcyBvbiBhYXJjaDY0LiBUaGlz IHdhcyBub3Qgc29tZQo+ID4gPiA+IGFjY2lkZW50YWwgY2hvaWNlLCB3ZSBoYWQgdG8gY2Fycnkg YSBwYXRjaCB0byBldmVuIGFsbG93IGl0IGZvciBhCj4gPiA+ID4gd2hpbGUuICBJZiB0aGlzIGRv ZXMgZ28gaW4gYXMgaXMsIHdlIHdpbGwgbGlrZWx5IGp1c3QgY2FycnkgYSBwYXRjaCB0bwo+ID4g PiA+IHJlbW92ZSB0aGUgImlmIEVYUEVSVCIsIGJ1dCB0aGF0IGlzIGEgYml0IG9mIGEgZGlzc2Vy dmljZSB0byB1c2VycyB3aG8KPiA+ID4gPiBtaWdodCBiZSB0cnlpbmcgdG8gZGVidWcgc29tZXRo aW5nIGVsc2UgdXBzdHJlYW0sIGJpc2VjdGluZyB1cHN0cmVhbQo+ID4gPiA+IGtlcm5lbHMgb3Ig dGVzdGluZyBhIHBhdGNoLiAgSW4gdGhvc2UgY2FzZXMsIHBlb3BsZSB0ZW5kIHRvIHVzZQo+ID4g PiA+IHByaXN0aW5lIHVwc3RyZWFtIHNvdXJjZXMgd2l0aG91dCBkaXN0cm8gcGF0Y2hlcyB0byB2 ZXJpZnksIGFuZCB0aGV5Cj4gPiA+ID4gdGVuZCB0byB1c2UgdGhlaXIgZXhpc3RpbmcgY29uZmln cy4gV2l0aCB0aGlzIGNoYW5nZSwgdGhlaXIgTUFYX09SREVSCj4gPiA+ID4gd2lsbCBkcm9wIHRv IDEwIGZyb20gMTMgc2lsZW50bHkuICAgVGhhdCBjYW4gbG9vayBsaWtlIGEgZGlmZmVyZW50Cj4g PiA+ID4gaXNzdWUgZW5vdWdoIHRvIHJ1aW4gYSBiaXNlY3Qgb3IgaGF2ZSB0aGVtIGdpdmUgYmFk IGZlZWRiYWNrIG9uIGEKPiA+ID4gPiBwYXRjaCBiZWNhdXNlIGl0IGludHJvZHVjZXMgYSAicmVn cmVzc2lvbiIgd2hpY2ggaXMgbm90IGEgcmVncmVzc2lvbgo+ID4gPiA+IGF0IGFsbCwgYnV0IGEg Y29uZmlnIGNoYW5nZSB0aGV5IGNvdWxkbid0IHNlZS4KPiA+ID4KPiA+ID4gSWYgd2UgcmVtb3Zl IEVYUEVSVCAoYXMgcHJpb3IgdG8gdGhpcyBwYXRjaCksIEknZCByYXRoZXIga2VlcCB0aGUgcmFu Z2VzCj4gPiA+IGFuZCBhdm9pZCBoYXZpbmcgdG8gZXhwbGFpbiB0byBwZW9wbGUgd2h5IHNvbWUg cmFuZG9tIE1BWF9PUkRFUiBkb2Vzbid0Cj4gPiA+IGJ1aWxkIChrZWVwaW5nIHRoZSByYW5nZSB3 b3VsZCBhbHNvIG1ha2Ugc2Vuc2UgZm9yIHJhbmRjb25maWcsIG5vdCBzdXJlCj4gPiA+IHdlIGdv dCB0byBhbnkgY29uY2x1c2lvbiB0aGVyZSkuCj4gPgo+ID4gV2VsbCB0aGlzIGRvZXNuJ3Qgc2Vl bSB0byBoYXZlIGdvdCBhbnl3aGVyZS4gIEkgdGhpbmsgSSdsbCBzZW5kIHRoZQo+ID4gcGF0Y2hz ZXQgaW50byBMaW51cyBmb3IgdGhlIG5leHQgbWVyZ2Ugd2luZG93IGFzLWlzLiAgUGxlYXNlIGxl dCdzIHRha2UKPiA+IGEgbG9vayBhdCB0aGlzIEtjb25maWcgcHJlc2VudGF0aW9uIGlzc3VlIGR1 cmluZyB0aGUgZm9sbG93aW5nIC1yYwo+ID4gY3ljbGUuCj4gCj4gV2VsbCwgSSBhbSB2ZXJ5IHNv cnJ5IHRvIHNlZSB0aGlzIGdvaW5nIGluIGFzIGlzLiAgSXQgd2lsbCBzaWxlbnRseQo+IGNoYW5n ZSBwZW9wbGUgYnVpbGRpbmcgd2l0aCBvbGRjb25maWcsIGFuZCBhbnlvbmUgbm90IHBheWluZyBh dHRlbnRpb24KPiB3aWxsIG5vdCBub3RpY2UgdW50aWwgYW4gaXNzdWUgaXMgaGl0IHdoZXJlICJp dCB3b3JrZWQgYmVmb3JlLCBhbmQgbXkKPiBjb25maWcgaGFzbid0IGNoYW5nZWQiLiAgSWYgRVhQ RVJUIGlzIHVuc2V0LCB0aGVyZSBpcyBubyBub3RpZmljYXRpb24sCj4ganVzdCBhIGNoYW5nZWQg YmVoYXZpb3IuICBXaGlsZSBpdCB3b3VsZCBiZSBlYXN5IGZvciBtZSB0byBjYXJyeSBhCj4gcGF0 Y2ggZHJvcHBpbmcgdGhlIGlmIEVYUEVSVCwgaXQgd2lsbCBub3QgaGVscCBhbnkgdXNlcnMgYnVp bGRpbmcgb24KPiB1cHN0cmVhbSB3aXRoIG91ciBjb25maWdzLCB3aGV0aGVyIGZvciB0aGVpciBv d24gcmVndWxhciB1c2UsIG9yIHdoaWxlCj4gdHJ5aW5nIHRvIGRlYnVnIG90aGVyIGlzc3Vlcywg IEkgZXhwZWN0IGl0IHdpbGwgcmVzdWx0IGluIGEgcmVhc29uYWJsZQo+IGFtb3VudCBvZiBmcnVz dHJhdGlvbiBmcm9tIHVzZXJzIHRyeWluZyB0byBkbyB0aGUgcmlnaHQgdGhpbmcgYW5kCj4gYmlz ZWN0IG9yIHRlc3QgcGF0Y2hlcyB1cHN0cmVhbS4KCkFzIEkgc2FpZCBpbiBhIHByZXZpb3VzIHJl cGx5LCBJJ20gZmluZSB3aXRoIHJldmVydGluZyB0aGlzIGNvbW1pdCBpZiBpdApicmVha3MgZXhp c3RpbmcgY29uZmlncy4gSXQncyBvbmx5IHRoYXQgQW5kcmV3IGhhZCBhbHJlYWR5IHF1ZXVlZCBp dCBpbgpoaXMgdHJlZSBidXQgd2UgaGF2ZSB0aW1lIHVudGlsIHRoZSBmaW5hbCA2LjQga2VybmVs IGlzIHJlbGVhc2VkLgoKVGhhdCBzYWlkLCB3b3VsZCB5b3UgbWluZCBzZW5kaW5nIGEgcGF0Y2gg cmV2ZXJ0aW5nIGl0IChpZiByZW1vdmluZwpFWFBFUlQsIEknZCBsaWtlIHRvIGtlZXAgdGhlIHJh bmdlcyk/IDspCgpUaGFua3MuCgotLSAKQ2F0YWxpbgoKX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18KbGludXgtYXJtLWtlcm5lbCBtYWlsaW5nIGxpc3QKbGlu dXgtYXJtLWtlcm5lbEBsaXN0cy5pbmZyYWRlYWQub3JnCmh0dHA6Ly9saXN0cy5pbmZyYWRlYWQu b3JnL21haWxtYW4vbGlzdGluZm8vbGludXgtYXJtLWtlcm5lbAo=