+(Summary: good solid orthogonal idea. See [[ioctl]] for full details)
+
+This proposal basically mirrors the concept of POSIX ioctls, providing
+(arbitrarily) 8 functions (opcodes) whose meaning may be over-ridden
+in an object-orientated fashion by calling an "open handle" (and close)
+function (instruction) that switches (redirects) the 8 functions over to
+different opcodes.
+
+The "open handle" opcode takes a GUID (globally-unique identifier)
+and an ioctl number, and stores the UUID in a table indexed by the
+ioctl number:
+
+ handle_global_state[8] # stores UUID or index of same
+
+ def open_handle(uuid, ioctl_num):
+ handle_global_state[ioctl_num] = uuid
+
+ def close_handle(ioctl_num):
+ handle_global_state[ioctl_num] = -1 # clear table entry
+
+"Ioctls" (arbitrarily 8 separate R-type opcodes) then perform a redirect
+based on what the global state for that numbered "ioctl" has been set to:
+
+ def ioctl_fn0(*rargs): # star means "take all arguments as a tuple"
+ if handle_global_state[0] == CUSTOMEXT1UUID:
+ CUSTOMEXT1_FN0(*rargs) # apply all arguments to function
+ elif handle_global_state[0] == CUSTOMEXT2UUID:
+ CUSTOMEXT2_FN0(*rargs) # apply all arguments to function
+ else:
+ raise Exception("undefined opcode")
+
+The proposal is functionally near-identical to that of the mvendor/march-id
+except extended down to individual opcodes. As such it could hypothetically
+be proposed as an independent Standard Extension in its own right that extends
+the Custom Opcode space *or* fits into the brownfield spaces within the
+existing ISA opcode space *or* is used as the basis of an independent
+Custom Extension in its own right.
+
+One of the reasons for seeking an extension of the Custom opcode space is
+that the Custom opcode space is severely limited: only 2 opcodes are free
+within the 32-bit space, and only four total remain in the 48 and 64-bit
+space.
+
+Despite the proposal (which is still undergoing clarification)
+being worthwhile in its own right, and standing on its own merits and
+thus definitely worthwhile pursuing, it is non-trivial and much more
+invasive than the mvendor/march-id WARL concept.
+
+# Comments, Discussion and analysis
+
+TBD: placeholder as of 26apr2018
+
+# Summary and Conclusion
+
+In the early sections (those in the category "no action") it was established
+in each case that the problem is not solved. Avoidance of responsibility,
+or conflation of "not our problem" with "no problem" does not make "problem"
+go away. Even "making it the Fabless Semiconductor's design problem" resulted
+in a chip being *more costly to engineer as hardware **and** more costly
+from a software-support perspective to maintain*... without actually
+fixing the problem.
+
+The first idea considered which could fix the problem was to just use
+the pre-existing MISA CSR, however this was determined not to have
+the right coverage (Standard Extensions only), and also crucially it
+destroyed state. Whilst unworkable it did lead to the first "workable"
+solution, "MISA-like".
+
+The "MISA-like" proposal, whilst meeting most of the requirements, led to
+a better idea: "mvendor/march-id WARL", which, in combination with an offshoot
+idea related to gcc and binutils, is the only proposal that fully meets the
+requirements.
+
+The "ioctl-like" idea *also* solves the problem, but, unlike the WARL idea
+does not meet the full requirements to be "non-invasive" and "backwards
+compatible" with pre-existing (pre-Standards-finalised) implementations.
+It does however stand on its own merit as a way to extend the extremely
+small Custom Extension opcode space, even if it itself implemented *as*
+a Custom Extension into which *other* Custom Extensions are subsequently
+shoe-horned. This approach has the advantage that it requires no "approval"
+from the RISC-V Foundation... but without the RISC-V Standard "approval"
+guaranteeing no binary-encoding conflicts, still does not actually solve the
+problem (if deployed as a Custom Extension for extending Custom Extensions).
+
+Overall the mvendor/march-id WARL idea meets the three requirements,
+and is the only idea that meets the three requirements:
+
+* **Any proposal must be a minimal change with minimal (or zero) impact**
+ (met through being purely a single change to the specification:
+ mvendor/march-id changes from read-only to WARL)
+* **Any proposal should place no restriction on existing or future
+ ISA encoding space**
+ (met because it is just a change to one pre-existing CSR)
+* **Any proposal should take into account that there are existing implementors
+ of the (yet to be finalised but still "partly frozen") Standard who may
+ resist, for financial investment reasons, efforts to make any change
+ (at all) that could cost them immediate short-term profits.**
+ (met because existing implementations, with the exception of those
+ that have Custom Extensions, come under the "vendor/arch-id read only
+ is a declaration of having no Custom Extensions" fall-back category)
+
+So to summarise:
+
+* The consequences of not tackling this are severe: the RISC-V Foundation
+ cannot take a back seat. If it does, clear historical precedent shows
+ 100% what the outcome will be (1).
+* The retro-fitting cost onto existing implementations (even though the
+ specification has not been finalised) is negligeable
+ (changes to words in the specification)
+* The benefits are clear (pain-free transition path for vendors to safely
+ upgrade over time; no fights over Custom opcode space; no hassle for
+ software toolchain; no hassle for GNU/Linux Distros)
+* The implementation details are clear (and problem-free except for
+ vendors who insist on deploying dozens of conflicting Custom Extensions:
+ an extreme unlikely outlier).
+* Compliance Testing is straightforward and allows vendors to seek and
+ obtain *multiple* Compliance Certificates with past, present and future
+ variants of the RISC-V Standard (in the exact same processor), in order
+ support legacy customers and provide same customers with a way to avoid
+ "impossible-to-make" decisions that throw out ultra-expensive multi-decade
+ proprietary legacy software at the same as the hardware.