+# ioctl-like
+
+==RB===
+
+This proposal adds a standardised extension interface to the RV
+instruction set by introducing a fixed small number (e.g. 8) of
+"overloadable" R-type opcodes ext_ctl0, .. ext_ctl7. Each takes a process
+local interface cookie in rs1. Based on the cookie, the CPU routes the
+"overloaded" instructions to a "device" on or off the CPU that implements
+the actual semantics.
+
+The cookie is "opened" with an additional r-type instruction ext_open that
+takes a 20 bit identifier and "closed" with an ext_close instruction. The
+implementing hardware device can use the cookie to reference internal
+state. Thus, interfaces may be statefull.
+
+CPU's and devices may implement several interfaces, indeed, are expected
+to. E.g. a single hardware device might expose a functional interface with
+6 overloaded instructions, expose configuration with two highly device
+specific management interfaces with 8 resp. 4 overloaded instructions,
+and respond to a standardised save state interface with 4 overloaded
+instructions.
+
+Having a standardised overloadable interface simply avoids much of the
+need for isa extensions for hardware with non standard interfaces and
+semantics. This is analogous to the way that the standardised overloadable
+ioctl interface of the kernel almost completely avoids the need for
+extending the kernel with syscalls for the myriad of hardware devices
+with their specific interfaces and semantics.
+
+Since the rs1 input of the overloaded ext_ctl instruction's are taken
+by the interface cookie, they are restricted in use compared to a normal
+R-type instruction (it is possible to pass 12 bits of additional info by
+or ing it with the cookie). Delegation is also expected to come at a small
+additional performance price compared to a "native" instruction. This
+should be an acceptable tradeoff in most cases.
+
+The expanded flexibility comes at the cost: the standard can specify the
+semantics of the delegation mechanism and the interfacing with the rest
+of the cpu, but the actual semantics of the overloaded instructions can
+only be defined by the designer of the interface. Likewise, a device
+can be conforming as far as delegation and interaction with the CPU
+is concerned, but whether the hardware is conforming to the semantics
+of the interface is outside the scope of spec. Being able to specify
+that semantics using the methods used for RV itself is clearly very
+valuable. One impetus for doing that is using it for purposes of its own,
+effectively freeing opcode space for other purposes. Also, some interfaces
+may become de facto or de jure standards themselves, necessitating
+hardware to implement competing interfaces. I.e., facilitating a free
+for all, may lead to standards proliferation. C'est la vie.