Status of the various RISC-V specification and policy

Status of the various RISC-V specification and policy

[Atish Patra]

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

--
Regards,
Atish

Mail from Stephano:
----------------------------------------------------------------------------------
Subject: Privileged Specification 1.12 Freeze Milestone: Public Review

All,

The Privileged Specification version 1.12 has gone to public review. You
can view the specification documents by following the links provided here:
https://docs.google.com/document/d/1soGI__HytotOkoJtgTYD0nzf82Zhp5nWw1Mcgqvbn8o/edit?usp=sharing

Review discussion can be followed on the ISA-DEV mailing list here:
https://groups.google.com/a/groups.riscv.org/g/isa-dev

The review period will be open for 45 days ending Sunday October 31, 2021.

We encourage all conversation to happen on this mailing list. Simply reply
to the posts linked above with any questions or comments. If you feel that
you have a topic that is best discussed internally with RISC-V members
only, please contact me directly.

Kind Regards,
Stephano
--
Stephano Cetola
Director of Technical Programs
RISC-V International
----------------------------------------------------------------------------------------------------

Re: Status of the various RISC-V specification and policy

[Palmer Dabbelt]

On Tue, 21 Sep 2021 17:20:17 PDT (-0700), atishp@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?

Re: Status of the various RISC-V specification and policy

[Palmer Dabbelt]

On Tue, 21 Sep 2021 17:20:17 PDT (-0700), atishp@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?

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: Status of the various RISC-V specification and policy

[Mark Himelstein]

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.

Mark
--------
sent from a mobile device. please forgive any typos.

> On Sep 27, 2021, at 8:50 AM, Palmer Dabbelt <palmer@dabbelt.com> wrote:
> 
> On Tue, 21 Sep 2021 17:20:17 PDT (-0700), atishp@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?

Re: Status of the various RISC-V specification and policy

[Palmer Dabbelt]

On Mon, 27 Sep 2021 08:57:15 PDT (-0700), markhimelstein@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 <palmer@dabbelt.com> wrote:
>> 
>> On Tue, 21 Sep 2021 17:20:17 PDT (-0700), atishp@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?

Re: Status of the various RISC-V specification and policy

[Palmer Dabbelt]

On Mon, 27 Sep 2021 08:57:15 PDT (-0700), markhimelstein@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 <palmer@dabbelt.com> wrote:
>> 
>> On Tue, 21 Sep 2021 17:20:17 PDT (-0700), atishp@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?

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: Status of the various RISC-V specification and policy

[Atish Patra]

On Tue, Sep 28, 2021 at 11:34 AM Palmer Dabbelt <palmer@dabbelt.com> wrote:
>
> On Mon, 27 Sep 2021 08:57:15 PDT (-0700), markhimelstein@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.)

Here is the list of the specs that are frozen.
https://wiki.riscv.org/display/TECH/ISA+Extensions+On+Deck+for+Freeze+Milestone
I will let Mark comment on the compatibility thing.

>
> >
> > Mark
> > --------
> > sent from a mobile device. please forgive any typos.
> >
> >> On Sep 27, 2021, at 8:50 AM, Palmer Dabbelt <palmer@dabbelt.com> wrote:
> >>
> >> On Tue, 21 Sep 2021 17:20:17 PDT (-0700), atishp@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?



-- 
Regards,
Atish

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: Status of the various RISC-V specification and policy

[Atish Patra]

On Tue, Sep 28, 2021 at 11:34 AM Palmer Dabbelt <palmer@dabbelt.com> wrote:
>
> On Mon, 27 Sep 2021 08:57:15 PDT (-0700), markhimelstein@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.)

Here is the list of the specs that are frozen.
https://wiki.riscv.org/display/TECH/ISA+Extensions+On+Deck+for+Freeze+Milestone
I will let Mark comment on the compatibility thing.

>
> >
> > Mark
> > --------
> > sent from a mobile device. please forgive any typos.
> >
> >> On Sep 27, 2021, at 8:50 AM, Palmer Dabbelt <palmer@dabbelt.com> wrote:
> >>
> >> On Tue, 21 Sep 2021 17:20:17 PDT (-0700), atishp@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?



-- 
Regards,
Atish

Re: Status of the various RISC-V specification and policy

[Palmer Dabbelt]

On Tue, 28 Sep 2021 13:05:53 PDT (-0700), atishp@atishpatra.org wrote:
> On Tue, Sep 28, 2021 at 11:34 AM Palmer Dabbelt <palmer@dabbelt.com> wrote:
>>
>> On Mon, 27 Sep 2021 08:57:15 PDT (-0700), markhimelstein@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.)
>
> Here is the list of the specs that are frozen.
> https://wiki.riscv.org/display/TECH/ISA+Extensions+On+Deck+for+Freeze+Milestone

How does that indicate what is frozen?  I see "ISA Extensions On Deck 
for Freeze Milestone" as the title, which makes it sound like these are 
extension that are not yet frozen but will be eventually.

Scrolling down to the end of that list, it lists pointer masking.  The 
best I can find is 
https://github.com/riscv/riscv-j-extension/blob/master/pointer-masking-proposal.adoc 
, which says "Version: v0.1-draft", which definately doesn't sound 
frozen.  The README says "Working Draft of the RISC-V J Extension 
Specification", which also doesn't sound frozen.

> I will let Mark comment on the compatibility thing.
>
>>
>> >
>> > Mark
>> > --------
>> > sent from a mobile device. please forgive any typos.
>> >
>> >> On Sep 27, 2021, at 8:50 AM, Palmer Dabbelt <palmer@dabbelt.com> wrote:
>> >>
>> >> On Tue, 21 Sep 2021 17:20:17 PDT (-0700), atishp@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?
>
>
>
> -- 
> Regards,
> Atish

Re: Status of the various RISC-V specification and policy

[Palmer Dabbelt]

On Tue, 28 Sep 2021 13:05:53 PDT (-0700), atishp@atishpatra.org wrote:
> On Tue, Sep 28, 2021 at 11:34 AM Palmer Dabbelt <palmer@dabbelt.com> wrote:
>>
>> On Mon, 27 Sep 2021 08:57:15 PDT (-0700), markhimelstein@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.)
>
> Here is the list of the specs that are frozen.
> https://wiki.riscv.org/display/TECH/ISA+Extensions+On+Deck+for+Freeze+Milestone

How does that indicate what is frozen?  I see "ISA Extensions On Deck 
for Freeze Milestone" as the title, which makes it sound like these are 
extension that are not yet frozen but will be eventually.

Scrolling down to the end of that list, it lists pointer masking.  The 
best I can find is 
https://github.com/riscv/riscv-j-extension/blob/master/pointer-masking-proposal.adoc 
, which says "Version: v0.1-draft", which definately doesn't sound 
frozen.  The README says "Working Draft of the RISC-V J Extension 
Specification", which also doesn't sound frozen.

> I will let Mark comment on the compatibility thing.
>
>>
>> >
>> > Mark
>> > --------
>> > sent from a mobile device. please forgive any typos.
>> >
>> >> On Sep 27, 2021, at 8:50 AM, Palmer Dabbelt <palmer@dabbelt.com> wrote:
>> >>
>> >> On Tue, 21 Sep 2021 17:20:17 PDT (-0700), atishp@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?
>
>
>
> -- 
> Regards,
> Atish

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: Status of the various RISC-V specification and policy

[Atish Patra]

On Tue, Sep 28, 2021 at 3:43 PM Palmer Dabbelt <palmer@dabbelt.com> wrote:
>
> On Tue, 28 Sep 2021 13:05:53 PDT (-0700), atishp@atishpatra.org wrote:
> > On Tue, Sep 28, 2021 at 11:34 AM Palmer Dabbelt <palmer@dabbelt.com> wrote:
> >>
> >> On Mon, 27 Sep 2021 08:57:15 PDT (-0700), markhimelstein@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.)
> >
> > Here is the list of the specs that are frozen.
> > https://wiki.riscv.org/display/TECH/ISA+Extensions+On+Deck+for+Freeze+Milestone
>
> How does that indicate what is frozen?  I see "ISA Extensions On Deck
> for Freeze Milestone" as the title, which makes it sound like these are
> extension that are not yet frozen but will be eventually.

Any row with "top sheet" complete and "out for public review" is frozen.
The life cycle document[1] that I shared earlier in this thread also
says the same i.e. any specification that is out for public review is
frozen.
Stephano also sent out a public email about all the specifications
that are frozen.

However, I understand that you need to do a little bit of deduction to
understand what is frozen.
@Stephano(already cc'd here)

Can you add a separate column clearly indicating that "Freeze" status
for each of those specifications in the wiki link.

[1] https://docs.google.com/presentation/d/1nQ5uFb39KA6gvUi5SReWfIQSiRN7hp6z7ZPfctE4mKk/edit#slide=id.p1
>
> Scrolling down to the end of that list, it lists pointer masking.  The
> best I can find is
> https://github.com/riscv/riscv-j-extension/blob/master/pointer-masking-proposal.adoc
> , which says "Version: v0.1-draft", which definately doesn't sound
> frozen.  The README says "Working Draft of the RISC-V J Extension
> Specification", which also doesn't sound frozen.
>
> > I will let Mark comment on the compatibility thing.
> >
> >>
> >> >
> >> > Mark
> >> > --------
> >> > sent from a mobile device. please forgive any typos.
> >> >
> >> >> On Sep 27, 2021, at 8:50 AM, Palmer Dabbelt <palmer@dabbelt.com> wrote:
> >> >>
> >> >> On Tue, 21 Sep 2021 17:20:17 PDT (-0700), atishp@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?
> >
> >
> >
> > --
> > Regards,
> > Atish



-- 
Regards,
Atish

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: Status of the various RISC-V specification and policy

[Atish Patra]

On Tue, Sep 28, 2021 at 3:43 PM Palmer Dabbelt <palmer@dabbelt.com> wrote:
>
> On Tue, 28 Sep 2021 13:05:53 PDT (-0700), atishp@atishpatra.org wrote:
> > On Tue, Sep 28, 2021 at 11:34 AM Palmer Dabbelt <palmer@dabbelt.com> wrote:
> >>
> >> On Mon, 27 Sep 2021 08:57:15 PDT (-0700), markhimelstein@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.)
> >
> > Here is the list of the specs that are frozen.
> > https://wiki.riscv.org/display/TECH/ISA+Extensions+On+Deck+for+Freeze+Milestone
>
> How does that indicate what is frozen?  I see "ISA Extensions On Deck
> for Freeze Milestone" as the title, which makes it sound like these are
> extension that are not yet frozen but will be eventually.

Any row with "top sheet" complete and "out for public review" is frozen.
The life cycle document[1] that I shared earlier in this thread also
says the same i.e. any specification that is out for public review is
frozen.
Stephano also sent out a public email about all the specifications
that are frozen.

However, I understand that you need to do a little bit of deduction to
understand what is frozen.
@Stephano(already cc'd here)

Can you add a separate column clearly indicating that "Freeze" status
for each of those specifications in the wiki link.

[1] https://docs.google.com/presentation/d/1nQ5uFb39KA6gvUi5SReWfIQSiRN7hp6z7ZPfctE4mKk/edit#slide=id.p1
>
> Scrolling down to the end of that list, it lists pointer masking.  The
> best I can find is
> https://github.com/riscv/riscv-j-extension/blob/master/pointer-masking-proposal.adoc
> , which says "Version: v0.1-draft", which definately doesn't sound
> frozen.  The README says "Working Draft of the RISC-V J Extension
> Specification", which also doesn't sound frozen.
>
> > I will let Mark comment on the compatibility thing.
> >
> >>
> >> >
> >> > Mark
> >> > --------
> >> > sent from a mobile device. please forgive any typos.
> >> >
> >> >> On Sep 27, 2021, at 8:50 AM, Palmer Dabbelt <palmer@dabbelt.com> wrote:
> >> >>
> >> >> On Tue, 21 Sep 2021 17:20:17 PDT (-0700), atishp@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?
> >
> >
> >
> > --
> > Regards,
> > Atish



-- 
Regards,
Atish

Re: Status of the various RISC-V specification and policy

[Palmer Dabbelt]

On Tue, 28 Sep 2021 16:23:56 PDT (-0700), atishp@atishpatra.org wrote:
> On Tue, Sep 28, 2021 at 3:43 PM Palmer Dabbelt <palmer@dabbelt.com> wrote:
>>
>> On Tue, 28 Sep 2021 13:05:53 PDT (-0700), atishp@atishpatra.org wrote:
>> > On Tue, Sep 28, 2021 at 11:34 AM Palmer Dabbelt <palmer@dabbelt.com> wrote:
>> >>
>> >> On Mon, 27 Sep 2021 08:57:15 PDT (-0700), markhimelstein@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.)
>> >
>> > Here is the list of the specs that are frozen.
>> > https://wiki.riscv.org/display/TECH/ISA+Extensions+On+Deck+for+Freeze+Milestone
>>
>> How does that indicate what is frozen?  I see "ISA Extensions On Deck
>> for Freeze Milestone" as the title, which makes it sound like these are
>> extension that are not yet frozen but will be eventually.
>
> Any row with "top sheet" complete and "out for public review" is frozen.
> The life cycle document[1] that I shared earlier in this thread also
> says the same i.e. any specification that is out for public review is
> frozen.
> Stephano also sent out a public email about all the specifications
> that are frozen.
>
> However, I understand that you need to do a little bit of deduction to
> understand what is frozen.
> @Stephano(already cc'd here)
>
> Can you add a separate column clearly indicating that "Freeze" status
> for each of those specifications in the wiki link.

Is meant to be the complete list of what is frozen?

I'd expect any list of things that are frozen to contain the specs we've 
been working with for a while (priv-1.11, all the user 2.0 specs, etc).  
There was some talk about the SBI stuff that was called out as frozen 
before this process not actually being frozen, are those other specs in 
the same spot and if so are they going to end up being frozen?

That reminds me about this other set of specifications, sometimes called 
software specifications.  There's a list of "Non-ISA Extensions On Deck 
for Freeze Milestone" here: 
https://wiki.riscv.org/display/TECH/Non-ISA+Extensions+On+Deck+for+Freeze+Milestone 
.  That's got a frozen column in the table, but the table itself is 
pretty much empty.  We've had a bunch of confusing statements about 
those specifications being frozen, were the statements inaccurate, is 
that table inaccurate, and will that table be an additional list of 
frozen specifications?

>
> [1] https://docs.google.com/presentation/d/1nQ5uFb39KA6gvUi5SReWfIQSiRN7hp6z7ZPfctE4mKk/edit#slide=id.p1
>>
>> Scrolling down to the end of that list, it lists pointer masking.  The
>> best I can find is
>> https://github.com/riscv/riscv-j-extension/blob/master/pointer-masking-proposal.adoc
>> , which says "Version: v0.1-draft", which definately doesn't sound
>> frozen.  The README says "Working Draft of the RISC-V J Extension
>> Specification", which also doesn't sound frozen.
>>
>> > I will let Mark comment on the compatibility thing.
>> >
>> >>
>> >> >
>> >> > Mark
>> >> > --------
>> >> > sent from a mobile device. please forgive any typos.
>> >> >
>> >> >> On Sep 27, 2021, at 8:50 AM, Palmer Dabbelt <palmer@dabbelt.com> wrote:
>> >> >>
>> >> >> On Tue, 21 Sep 2021 17:20:17 PDT (-0700), atishp@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?
>> >
>> >
>> >
>> > --
>> > Regards,
>> > Atish
>
>
>
> -- 
> Regards,
> Atish

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: Status of the various RISC-V specification and policy

[Palmer Dabbelt]

On Tue, 28 Sep 2021 16:23:56 PDT (-0700), atishp@atishpatra.org wrote:
> On Tue, Sep 28, 2021 at 3:43 PM Palmer Dabbelt <palmer@dabbelt.com> wrote:
>>
>> On Tue, 28 Sep 2021 13:05:53 PDT (-0700), atishp@atishpatra.org wrote:
>> > On Tue, Sep 28, 2021 at 11:34 AM Palmer Dabbelt <palmer@dabbelt.com> wrote:
>> >>
>> >> On Mon, 27 Sep 2021 08:57:15 PDT (-0700), markhimelstein@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.)
>> >
>> > Here is the list of the specs that are frozen.
>> > https://wiki.riscv.org/display/TECH/ISA+Extensions+On+Deck+for+Freeze+Milestone
>>
>> How does that indicate what is frozen?  I see "ISA Extensions On Deck
>> for Freeze Milestone" as the title, which makes it sound like these are
>> extension that are not yet frozen but will be eventually.
>
> Any row with "top sheet" complete and "out for public review" is frozen.
> The life cycle document[1] that I shared earlier in this thread also
> says the same i.e. any specification that is out for public review is
> frozen.
> Stephano also sent out a public email about all the specifications
> that are frozen.
>
> However, I understand that you need to do a little bit of deduction to
> understand what is frozen.
> @Stephano(already cc'd here)
>
> Can you add a separate column clearly indicating that "Freeze" status
> for each of those specifications in the wiki link.

Is meant to be the complete list of what is frozen?

I'd expect any list of things that are frozen to contain the specs we've 
been working with for a while (priv-1.11, all the user 2.0 specs, etc).  
There was some talk about the SBI stuff that was called out as frozen 
before this process not actually being frozen, are those other specs in 
the same spot and if so are they going to end up being frozen?

That reminds me about this other set of specifications, sometimes called 
software specifications.  There's a list of "Non-ISA Extensions On Deck 
for Freeze Milestone" here: 
https://wiki.riscv.org/display/TECH/Non-ISA+Extensions+On+Deck+for+Freeze+Milestone 
.  That's got a frozen column in the table, but the table itself is 
pretty much empty.  We've had a bunch of confusing statements about 
those specifications being frozen, were the statements inaccurate, is 
that table inaccurate, and will that table be an additional list of 
frozen specifications?

>
> [1] https://docs.google.com/presentation/d/1nQ5uFb39KA6gvUi5SReWfIQSiRN7hp6z7ZPfctE4mKk/edit#slide=id.p1
>>
>> Scrolling down to the end of that list, it lists pointer masking.  The
>> best I can find is
>> https://github.com/riscv/riscv-j-extension/blob/master/pointer-masking-proposal.adoc
>> , which says "Version: v0.1-draft", which definately doesn't sound
>> frozen.  The README says "Working Draft of the RISC-V J Extension
>> Specification", which also doesn't sound frozen.
>>
>> > I will let Mark comment on the compatibility thing.
>> >
>> >>
>> >> >
>> >> > Mark
>> >> > --------
>> >> > sent from a mobile device. please forgive any typos.
>> >> >
>> >> >> On Sep 27, 2021, at 8:50 AM, Palmer Dabbelt <palmer@dabbelt.com> wrote:
>> >> >>
>> >> >> On Tue, 21 Sep 2021 17:20:17 PDT (-0700), atishp@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?
>> >
>> >
>> >
>> > --
>> > Regards,
>> > Atish
>
>
>
> -- 
> Regards,
> Atish

Re: Status of the various RISC-V specification and policy

[Mark Himelstein]

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.



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 <palmer@dabbelt.com> wrote:

> On Mon, 27 Sep 2021 08:57:15 PDT (-0700), markhimelstein@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 <palmer@dabbelt.com> wrote:
> >>
> >> On Tue, 21 Sep 2021 17:20:17 PDT (-0700), atishp@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?
>

Re: Status of the various RISC-V specification and policy

[Palmer Dabbelt]

On Thu, 30 Sep 2021 08:06:42 PDT (-0700), markhimelstein@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 <palmer@dabbelt.com> wrote:
>
>> On Mon, 27 Sep 2021 08:57:15 PDT (-0700), markhimelstein@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 <palmer@dabbelt.com> wrote:
>> >>
>> >> On Tue, 21 Sep 2021 17:20:17 PDT (-0700), atishp@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?
>>

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: Status of the various RISC-V specification and policy

[Palmer Dabbelt]

On Thu, 30 Sep 2021 08:06:42 PDT (-0700), markhimelstein@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 <palmer@dabbelt.com> wrote:
>
>> On Mon, 27 Sep 2021 08:57:15 PDT (-0700), markhimelstein@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 <palmer@dabbelt.com> wrote:
>> >>
>> >> On Tue, 21 Sep 2021 17:20:17 PDT (-0700), atishp@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?
>>

Re: Status of the various RISC-V specification and policy

[Mark Himelstein]

The following is the extension lifecycle. It includes the official names
going forward for each phase. We are trying to resolve any confusion naming
and numbering and are still in progress of this evolution:

https://docs.google.com/presentation/d/1nQ5uFb39KA6gvUi5SReWfIQSiRN7hp6z7ZPfctE4mKk/edit?usp=sharing

Again, if we can improve anything to make it clearer or if we got something
wrong, please let us know.

Mark

On Thu, Sep 30, 2021 at 10:30 AM Palmer Dabbelt <palmer@dabbelt.com> wrote:

> On Thu, 30 Sep 2021 08:06:42 PDT (-0700), markhimelstein@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 <palmer@dabbelt.com>
> wrote:
> >
> >> On Mon, 27 Sep 2021 08:57:15 PDT (-0700), markhimelstein@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 <palmer@dabbelt.com>
> wrote:
> >> >>
> >> >> On Tue, 21 Sep 2021 17:20:17 PDT (-0700), atishp@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?
> >>
>

Re: Status of the various RISC-V specification and policy

[Palmer Dabbelt]

On Thu, 30 Sep 2021 10:38:02 PDT (-0700), markhimelstein@riscv.org wrote:
> The following is the extension lifecycle. It includes the official names
> going forward for each phase. We are trying to resolve any confusion naming
> and numbering and are still in progress of this evolution:
>
> https://docs.google.com/presentation/d/1nQ5uFb39KA6gvUi5SReWfIQSiRN7hp6z7ZPfctE4mKk/edit?usp=sharing
>
> Again, if we can improve anything to make it clearer or if we got something
> wrong, please let us know.

That is, unfortunately, even more confusing.

Slide 3 lists the milestones, but that uses very different terms than 
the "Specification States" wiki entry I was linked to earlier as the 
canonical definition of the process.  I'm also now less sure about what 
exactly is being frozen, as the slides seem to mix up extension and 
specification (which is the core of what I'm worried about).

Looking at slide 4 (titled "Extension Lifecycle"), I see a bunch of 
version number looking strings (things like "v0.1" and "v1.0-rcN 
(final)").  Are those versions, and if so what do they version?

It also says "v1.0 (ratified)" with an arrow pointing directly after 
"TSC Ratification Review & Vote", but in the v-1.0 tag I see "Once ratified, 
the spec will be given version 2.0."  Are these version-number-looking 
strings supposed to be things that exist within the same namespace?

Just loking over the slide again I see "New or Changed Features 
Specification Development become a new extension -- Go back to the top 
left".  That sort of seems like something that might help answer some of 
my core questionsn here around what's allowed to change when, but I'm 
genuinely not sure how to parse the words.  Might not be the most 
important thing to focus on now, though.

>
> Mark
>
> On Thu, Sep 30, 2021 at 10:30 AM Palmer Dabbelt <palmer@dabbelt.com> wrote:
>
>> On Thu, 30 Sep 2021 08:06:42 PDT (-0700), markhimelstein@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 <palmer@dabbelt.com>
>> wrote:
>> >
>> >> On Mon, 27 Sep 2021 08:57:15 PDT (-0700), markhimelstein@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 <palmer@dabbelt.com>
>> wrote:
>> >> >>
>> >> >> On Tue, 21 Sep 2021 17:20:17 PDT (-0700), atishp@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?
>> >>
>>

Re: Status of the various RISC-V specification and policy

[Palmer Dabbelt]

On Thu, 30 Sep 2021 10:38:02 PDT (-0700), markhimelstein@riscv.org wrote:
> The following is the extension lifecycle. It includes the official names
> going forward for each phase. We are trying to resolve any confusion naming
> and numbering and are still in progress of this evolution:
>
> https://docs.google.com/presentation/d/1nQ5uFb39KA6gvUi5SReWfIQSiRN7hp6z7ZPfctE4mKk/edit?usp=sharing
>
> Again, if we can improve anything to make it clearer or if we got something
> wrong, please let us know.

That is, unfortunately, even more confusing.

Slide 3 lists the milestones, but that uses very different terms than 
the "Specification States" wiki entry I was linked to earlier as the 
canonical definition of the process.  I'm also now less sure about what 
exactly is being frozen, as the slides seem to mix up extension and 
specification (which is the core of what I'm worried about).

Looking at slide 4 (titled "Extension Lifecycle"), I see a bunch of 
version number looking strings (things like "v0.1" and "v1.0-rcN 
(final)").  Are those versions, and if so what do they version?

It also says "v1.0 (ratified)" with an arrow pointing directly after 
"TSC Ratification Review & Vote", but in the v-1.0 tag I see "Once ratified, 
the spec will be given version 2.0."  Are these version-number-looking 
strings supposed to be things that exist within the same namespace?

Just loking over the slide again I see "New or Changed Features 
Specification Development become a new extension -- Go back to the top 
left".  That sort of seems like something that might help answer some of 
my core questionsn here around what's allowed to change when, but I'm 
genuinely not sure how to parse the words.  Might not be the most 
important thing to focus on now, though.

>
> Mark
>
> On Thu, Sep 30, 2021 at 10:30 AM Palmer Dabbelt <palmer@dabbelt.com> wrote:
>
>> On Thu, 30 Sep 2021 08:06:42 PDT (-0700), markhimelstein@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 <palmer@dabbelt.com>
>> wrote:
>> >
>> >> On Mon, 27 Sep 2021 08:57:15 PDT (-0700), markhimelstein@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 <palmer@dabbelt.com>
>> wrote:
>> >> >>
>> >> >> On Tue, 21 Sep 2021 17:20:17 PDT (-0700), atishp@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?
>> >>
>>

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv