public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: lkcl <luke.leighton@gmail.com>
To: binutils@sourceware.org,binutils-request@sourceware.org
Subject: Re: [PATCH v1] RISC-V: Support XVentanaCondOps extension
Date: Wed, 20 Apr 2022 17:55:01 +0000	[thread overview]
Message-ID: <C1BE526B-6CF1-4929-8AA2-8FD7BB67093C@gmail.com> (raw)
In-Reply-To: <mailman.26390.1650459569.2100866.binutils@sourceware.org>

sorry this is out of replyto because i am subscribed digest.

> 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, under any circumstances, to hit "upstream", due to the risk of creating massive conflict and confusion due to dominance of one extension over another, particularly if that custom extension achieves extremely commonly-used and high profile public status.

[a dynamic plugin system on the other hand is a completely different matter]

i warned the RISC-V Foundation about this scenario.  they ignored my warnings.  two years later as a recent article online outlines, the fragmentation has already occurred because this 3rd category (abuse of custom extension opcode space for *high profile* common public usage) has, as i warned would happen, in fact occurred.

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.

[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 toolchain you risk destruction of the entire ecosystem for everyone.

[by complete contrast a dynamic plugin system helps keep such rogue extensions "at bay", crucially *without* giving the false and misleading impression that the extensions have been "authorised" through upstream acceptance]

if unfamiliar with this scenario recall the nightmare opcode conflict of altivec for powerpc, of 20 years ago.  ask around.

l.

       reply	other threads:[~2022-04-20 17:55 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <mailman.26390.1650459569.2100866.binutils@sourceware.org>
2022-04-20 17:55 ` lkcl [this message]
2022-04-20 22:15   ` Jim Wilson
2022-04-20 23:17     ` lkcl
2022-01-09 19:29 Philipp Tomsich
2022-01-17 12:57 ` Philipp Tomsich
2022-04-20 11:37 ` Philipp Tomsich
2022-04-20 12:42   ` Kito Cheng
2022-04-22 10:37     ` Philipp Tomsich
2022-04-23  1:42       ` Kito Cheng
2022-04-25  9:38         ` Nelson Chu
2022-05-12 19:59           ` Philipp Tomsich
2022-05-12 22:23             ` Palmer Dabbelt
2022-05-13  7:55               ` Philipp Tomsich
2022-05-26 19:50               ` Philipp Tomsich
2022-05-30 19:33                 ` Palmer Dabbelt
2022-05-30 20:09                   ` Philipp Tomsich
2023-04-25 10:48     ` Philipp Tomsich
2023-04-26 20:34       ` Jeff Law

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=C1BE526B-6CF1-4929-8AA2-8FD7BB67093C@gmail.com \
    --to=luke.leighton@gmail.com \
    --cc=binutils-request@sourceware.org \
    --cc=binutils@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).