On Thu, 30 Sep 2021 08:06:42 PDT (-0700), markhimelst...@riscv.org wrote:
Palmer,
Thank you for your input.
Our strong intention is to not change specs once frozen. I speak for the
committees here and say that, in our opinion, declaring something frozen
sets a very high bar for making any changes and is sufficient to allow code
supporting an extension to be upstreamed. Of course if an unexpected and
significant issue is discovered during the public review that absolutely
must be addressed and cannot be deferred to a future extension (where the
cost of not addressing the issue exceeds the cost of addressing it. for
example introduces security vulnerabilities), then we will do so, as anyone
should expect from a public review.
We do not have versions of extensions. If an extension has a problem once
ratified, we will issue errata. All implementers have to publish the errata
if they use branding. We may release a new extension with the bulk of the
original extension plus the errata fix at some future date.
This is probably at the core of my confusion here.
At the preface of the user ISA there is a table with the headings
"Extension", "Version", and "Frozen"; contains a list of letters that
look like extension name; and contains a list of numbers that look like
versions of those extensions.
That nomenclature seems to carry on to some more recent specifications.
For example the first page of
https://github.com/riscv/riscv-v-spec/releases/download/v1.0/riscv-v-spec-1.0.pdf
(tagged 11 days ago) is
RISC-V "V" Vector Extension
Version 1.0
I'm happy to answer the rest of the questions here, but I think trying
to get on the same page about what is versioned and is proabbly the
first step because that's a pretty key component of my worries.
New extensions reserve the right to be incompatible with existing
extensions but our philosophy is very much to minimize that and only allow
the rare well-justified exceptions. Reasons may include errata, security
issues discovered, or new functionality we need to add that justifies
creating an incompatibility, etc.
What specifically do you see as an issue? What are you blocked on by our
conventions? We need specific details to resolve any issues. Right now, I
don't feel I have enough information from you.
Thanks
Mark
P.S. We had some situations in the past, in part due to vendors not waiting
for the specification processes to conclude, where implementers implemented
non-confoming chips either with vendor-specific extensions using reserved
opcodes and state, or implementing early drafts of standards-track
proposals in the development state (will likely change). This is in the
past and resolved. Anyone implementing non-standard extensions must
advertise them as such and make it clear that these are not standard RISC-V
extensions: this should make it clear for upstream projects that they will
be dealing with the respective vendors for support and maintenance, and
that any code implementing support for these extensions will be different
from what covers the respective standard extensions. Whether upstream
projects accept such changes, and what conditions they stipulate for
acceptance of these changes, are beyond the control of RISC-V. We also, as
I have described to you many times, have instituted mandatory standards
specification states for the front page of each specification to ensure
clarity (any divergence from this is a bug and we work to fix these
quickly).
On Tue, Sep 28, 2021 at 11:34 AM Palmer Dabbelt <pal...@dabbelt.com> wrote:
On Mon, 27 Sep 2021 08:57:15 PDT (-0700), markhimelst...@riscv.org wrote:
> the words in this document :
>
>
https://wiki.riscv.org/plugins/servlet/mobile?contentId=13098230#content/view/13098230
>
> make it very clear when changes are allowed or not and likely or not.
>
> if you think the verbiage is somehow ambiguous please help us make it
better.
I'm not really worried about changes, I'm worried about a committment to
future compatibility. When we take code into the kernel (and most other
core systems projects) we're taking on the burden of supporting (until
someone can prove there are no more users), which is very difficult to
do when the ISA changes in an incompatible fashion. The whole point of
agreeing on the frozen thing was that it gave us a committment from the
specifcation authors that the future ISA would be compatible with th
frozen extensions.
We're already in this spot with the V extension and the whole stable
thing, this definitaion of frozen looks very much like what was has led
to the issues there. Saying the spec won't change really isn't
meaningful, it's saying future specs will be compatible that's
important. Nothing in this whole rule touches on compatibility, and I
really don't want to end up in a bigger mess than we're already in.
(Also: some PGE subcontractor drove a crane into my house, so things are
a bit chaotic on my end. If you have that list of what's officially
frozen, can you send it out? I'll try to take a look ASAP, as then I
can at least focus the discussion on what's relevant right now.)
>
> Mark
> --------
> sent from a mobile device. please forgive any typos.
>
>> On Sep 27, 2021, at 8:50 AM, Palmer Dabbelt <pal...@dabbelt.com> wrote:
>>
>> On Tue, 21 Sep 2021 17:20:17 PDT (-0700), ati...@atishpatra.org wrote:
>>> Hi All,
>>> Please find the below email from Stephano about the freeze
announcement for
>>> various RISC-V specifications that will be part of privilege
specification
>>> v1.12.
>>> All the review discussions are happening in the isa-dev mailing list.
The
>>> review period will be open for 45 days ending Sunday October 31, 2021.
>>>
>>> I just want to highlight the fact that the *H*, *V, SvPBMT, CMO
extensions
>>> are frozen now. *This will help us merge some patches that have been
>>> present in the mailing list for a while.
>>>
>>> Here are the ratification policy and extension life cycle documents
present
>>> in the public. If you have any questions regarding this, please check
with
>>> Mark/Stephano (cc'd).
>>>
>>> Ratification policy:
>>>
https://docs.google.com/document/d/1-UlaSGqk59_myeuPMrV9gyuaIgnmFzGh5Gfy_tpViwM/edit
>>>
>>> Extension life cycle:
>>>
https://docs.google.com/presentation/d/1nQ5uFb39KA6gvUi5SReWfIQSiRN7hp6z7ZPfctE4mKk/edit#slide=id.p1
>>
>> I'm still buried after Plumbers, but one of the bits on my TODO list
was to look throught the new definitions for frozen and stable. Nothing in
this extension life cycle talks about the point at which compatibility will
be maintained, which was really the central point behind frozen before.
>>
>> Are there more concrete definitions somewhere?
