On Sat, Oct 30, 2021 at 01:36:07AM -0700, Greg Favor wrote:

On Fri, Oct 29, 2021 at 8:26 AM Ved Shanbhogue <ved@...> wrote:

Since Sscofmpf is still not ratified a second extension could be avoided
if its just
folded into the current extension. Is that an option?

Over the past year RVI (the TSC especially) has clearly moved towards
expecting extensions to be developed as smaller separate extensions instead
of being glommed together in longer development efforts. TG's going
forward will all have tightly focused and well defined charters, with a
more bounded timeline to produce a specific ratified standard. The intent
is to standardize basic important functionality sooner, and then come back
around in a second (or even third) development phase to standardize
secondary features, additional features, and/or feature enhancements. (The
CMO group is an example of this.) Fast track extensions are intended to
focus on one limited architecture extension; further fast track
extensions can add on further features.

Also note that adding functionality to an extension while in development is
not just a matter of writing a larger spec, but of expanding the amount
of work to be done with respect to all the required DoD (Definition of
Done) tasks (e.g. ACTs, Spike/QEMU/SAIL support, toolchain and
software support, PoCs).

Totally agree its not just a matter of writing a larger specification. My observation
in this specific case was that its not creating fundamentally new architecture. The CSR
we discussed would likely follow the rules of other mhpmevent CSR and not likely create
unique new architecture. Further I was observing that software had workaround being built
in to address this issue and it may ease software enabling by not needing to carry the
workaround.

A new extension would be fine as well. Software can pick between invoking the work around
or not based on existence of the new extension.

regards
ved