From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ed1-x52d.google.com (mail-ed1-x52d.google.com [IPv6:2a00:1450:4864:20::52d]) by sourceware.org (Postfix) with ESMTPS id 1695F3858D1E; Wed, 20 Apr 2022 17:55:07 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 1695F3858D1E Received: by mail-ed1-x52d.google.com with SMTP id t25so3297901edt.9; Wed, 20 Apr 2022 10:55:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:in-reply-to:references:mime-version :content-transfer-encoding:subject:to:from:message-id; bh=D4sgJ2n1jrmnXR515+erxGvUQ9qnoirRRJ1i5h8fVP4=; b=1AaOmioRzCElma46LUzfneQ0J4H0WJPLma017y6Ep1pvcV8dqBOzmsD4Vf1R8SPbnP j4DZxHu4Gk+2a0SsWeiDxVJIXNLmtXoXHRceXJ5FrWu4BB1b6VBIP14f1XqIfm8K3Inl vf5fnibMV70WI9Ekulyv6Eb2abiw64aL9iHYnFG9cwmvKAvIOvXw/wi4RbfKzyE0Mxxz cA+knN7zVDyU/MunVP/PyvJQWOAH3yFYIfIJ7tHwplq4ORbyX3XVfTv1HtN8T1nfNwk3 lR9fa1JC++jxt/axxcQIv6InEQZLqHFw/3kX378z4s/cLTiH4olqSuEVpDQMHi7Uyd9+ 1mEw== X-Gm-Message-State: AOAM530my1b8V0ATSoDXYZjTUIcWwSWEqiY0mZco/hmPt5iRbsnswQPx IA/RIkFNzPz3MpgTeq8q2gIgab97VuI= X-Google-Smtp-Source: ABdhPJzX7TlkIC/oNL0dHZnbe9SoIzJEglwfZuWs0HO0rjOi1zN8zSnECBw9ZO13LwPYdV5+Cfh5CA== X-Received: by 2002:a50:c3c6:0:b0:416:293f:1f42 with SMTP id i6-20020a50c3c6000000b00416293f1f42mr24571216edf.187.1650477305765; Wed, 20 Apr 2022 10:55:05 -0700 (PDT) Received: from [192.168.1.100] (92.40.171.129.threembb.co.uk. [92.40.171.129]) by smtp.gmail.com with ESMTPSA id k19-20020a1709061c1300b006e8843b0729sm6943725ejg.76.2022.04.20.10.55.04 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 20 Apr 2022 10:55:05 -0700 (PDT) Date: Wed, 20 Apr 2022 17:55:01 +0000 In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [PATCH v1] RISC-V: Support XVentanaCondOps extension To: binutils@sourceware.org,binutils-request@sourceware.org From: lkcl Message-ID: X-Spam-Status: No, score=2.5 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, RCVD_IN_ABUSEAT, RCVD_IN_BARRACUDACENTRAL, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.4 X-Spam-Level: ** X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: binutils@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Binutils mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2022 17:55:08 -0000 sorry this is out of replyto because i am subscribed digest=2E > Subject: Re: [PATCH v1] RISC-V: Support XVentanaCondOps extension > Hi Philipp: > I believe we have a consensus among most GNU toolchain maintainers for > accepting vendor extension to upstream / master branch, my understanding of custom extensions is that they are intended never, und= er any circumstances, to hit "upstream", due to the risk of creating massiv= e conflict and confusion due to dominance of one extension over another, pa= rticularly if that custom extension achieves extremely commonly-used and hi= gh profile public status=2E [a dynamic plugin system on the other hand is a completely different matte= r] i warned the RISC-V Foundation about this scenario=2E they ignored my war= nings=2E two years later as a recent article online outlines, the fragment= ation has already occurred because this 3rd category (abuse of custom exten= sion opcode space for *high profile* common public usage) has, as i warned = would happen, in fact occurred=2E custom extensions were *supposed* to be hard-forks of the entire toolchain= , maintained by a proprietary vendor, at their cost and expense, for their = benefit and their benefit only=2E [a dynamic plugin system helps such proprietary vendors to reduce costs of= maintaining such private hard forks] if you accept proprietary (rogue, unauthorized) custom plugins into the to= olchain you risk destruction of the entire ecosystem for everyone=2E [by complete contrast a dynamic plugin system helps keep such rogue extens= ions "at bay", crucially *without* giving the false and misleading impressi= on that the extensions have been "authorised" through upstream acceptance] if unfamiliar with this scenario recall the nightmare opcode conflict of a= ltivec for powerpc, of 20 years ago=2E ask around=2E l=2E