| Message ID | 20220920140138.27210-3-palmer@rivosinc.com (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
| Series | [1/3] Documentation: RISC-V: Fix a typo in patch-acceptance | expand |
On Tue, Sep 20, 2022 at 07:01:41AM -0700, Palmer Dabbelt wrote: > The current patch acceptance policy requires that specifications are > approved by the RISC-V foundation, but we rely on external > specifications as well. This explicitly calls out the UEFI > specifications that we're starting to depend on. > > Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com> > --- > This also came up during the Plumbers BoF. The other discussed options > were to wait for an ACPI/UEFI specification to be published or to just > not wait at all, but this middle ground matches how we handle the RISC-V > specifications and it seems like there was broad agreement on it. > > As usual with policy stuff I'll wait a bit for others to have a chance > to chime in, but I think the wording on this one is at least easier to > reason about than some of the others. > --- > Documentation/riscv/patch-acceptance.rst | 8 +++++--- > 1 file changed, 5 insertions(+), 3 deletions(-) > > diff --git a/Documentation/riscv/patch-acceptance.rst b/Documentation/riscv/patch-acceptance.rst > index 8087718556da..08cb92324eaf 100644 > --- a/Documentation/riscv/patch-acceptance.rst > +++ b/Documentation/riscv/patch-acceptance.rst > @@ -20,9 +20,11 @@ Submit Checklist Addendum > ------------------------- > We'll only accept patches for new modules or extensions if the > specifications for those modules or extensions are listed as being > +unlikely to make incompatible changes in the future. For Nit, but the wording here is awkward since it sounds like the module or extension is the "actor". How about: s/make incompatible changes/be incompatibly changed/ > +specifications from the RISC-V foundation this means "Frozen" or > +"Ratified", for the UEFI specifications this means a published ECR. > +(Developers may, of course, maintain their own Linux kernel trees that > +contain code for any draft extensions that they wish.) Could we just drop the brackets from this sentence? Either way, policy wise/idealogically this again looks good to me, so with or without the wording changed: Reviewed-by: Conor Dooley <conor.dooley@microchip.com> > Additionally, the RISC-V specification allows implementors to create > their own custom extensions. These custom extensions aren't required Thanks, Conor.
On Tue, Sep 20, 2022 at 7:31 AM Palmer Dabbelt <palmer@rivosinc.com> wrote: > > The current patch acceptance policy requires that specifications are > approved by the RISC-V foundation, but we rely on external > specifications as well. This explicitly calls out the UEFI > specifications that we're starting to depend on. > > Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com> > --- > This also came up during the Plumbers BoF. The other discussed options > were to wait for an ACPI/UEFI specification to be published or to just > not wait at all, but this middle ground matches how we handle the RISC-V > specifications and it seems like there was broad agreement on it. > > As usual with policy stuff I'll wait a bit for others to have a chance > to chime in, but I think the wording on this one is at least easier to > reason about than some of the others. > --- > Documentation/riscv/patch-acceptance.rst | 8 +++++--- > 1 file changed, 5 insertions(+), 3 deletions(-) > > diff --git a/Documentation/riscv/patch-acceptance.rst b/Documentation/riscv/patch-acceptance.rst > index 8087718556da..08cb92324eaf 100644 > --- a/Documentation/riscv/patch-acceptance.rst > +++ b/Documentation/riscv/patch-acceptance.rst > @@ -20,9 +20,11 @@ Submit Checklist Addendum > ------------------------- > We'll only accept patches for new modules or extensions if the > specifications for those modules or extensions are listed as being > -"Frozen" or "Ratified" by the RISC-V Foundation. (Developers may, of > -course, maintain their own Linux kernel trees that contain code for > -any draft extensions that they wish.) > +unlikely to make incompatible changes in the future. For > +specifications from the RISC-V foundation this means "Frozen" or > +"Ratified", for the UEFI specifications this means a published ECR. It would be good to explicitly mention "UEFI forum specifications" or UEFI/ACPI specifications. > +(Developers may, of course, maintain their own Linux kernel trees that > +contain code for any draft extensions that they wish.) > > Additionally, the RISC-V specification allows implementors to create > their own custom extensions. These custom extensions aren't required > -- > 2.34.1 > > > _______________________________________________ > linux-riscv mailing list > linux-riscv@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-riscv Other than that, LGTM Reviewed-by: Atish Patra <atishp@rivosinc.com>
On Tue, 20 Sep 2022 10:49:08 PDT (-0700), Conor Dooley wrote: > On Tue, Sep 20, 2022 at 07:01:41AM -0700, Palmer Dabbelt wrote: >> The current patch acceptance policy requires that specifications are >> approved by the RISC-V foundation, but we rely on external >> specifications as well. This explicitly calls out the UEFI >> specifications that we're starting to depend on. >> >> Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com> >> --- >> This also came up during the Plumbers BoF. The other discussed options >> were to wait for an ACPI/UEFI specification to be published or to just >> not wait at all, but this middle ground matches how we handle the RISC-V >> specifications and it seems like there was broad agreement on it. >> >> As usual with policy stuff I'll wait a bit for others to have a chance >> to chime in, but I think the wording on this one is at least easier to >> reason about than some of the others. >> --- >> Documentation/riscv/patch-acceptance.rst | 8 +++++--- >> 1 file changed, 5 insertions(+), 3 deletions(-) >> >> diff --git a/Documentation/riscv/patch-acceptance.rst b/Documentation/riscv/patch-acceptance.rst >> index 8087718556da..08cb92324eaf 100644 >> --- a/Documentation/riscv/patch-acceptance.rst >> +++ b/Documentation/riscv/patch-acceptance.rst >> @@ -20,9 +20,11 @@ Submit Checklist Addendum >> ------------------------- >> We'll only accept patches for new modules or extensions if the >> specifications for those modules or extensions are listed as being > >> +unlikely to make incompatible changes in the future. For > > Nit, but the wording here is awkward since it sounds like the module or > extension is the "actor". How about: > s/make incompatible changes/be incompatibly changed/ Makes sense, it's in the v2. >> +specifications from the RISC-V foundation this means "Frozen" or >> +"Ratified", for the UEFI specifications this means a published ECR. >> +(Developers may, of course, maintain their own Linux kernel trees that >> +contain code for any draft extensions that they wish.) > > Could we just drop the brackets from this sentence? IMO we should keep it, there was some confusion about how kernel trees work when we were at Plumbers. > > Either way, policy wise/idealogically this again looks good to me, so > with or without the wording changed: > Reviewed-by: Conor Dooley <conor.dooley@microchip.com> > >> Additionally, the RISC-V specification allows implementors to create >> their own custom extensions. These custom extensions aren't required > > Thanks, > Conor.
On Mon, 26 Sep 2022 10:34:07 PDT (-0700), atishp@atishpatra.org wrote: > On Tue, Sep 20, 2022 at 7:31 AM Palmer Dabbelt <palmer@rivosinc.com> wrote: >> >> The current patch acceptance policy requires that specifications are >> approved by the RISC-V foundation, but we rely on external >> specifications as well. This explicitly calls out the UEFI >> specifications that we're starting to depend on. >> >> Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com> >> --- >> This also came up during the Plumbers BoF. The other discussed options >> were to wait for an ACPI/UEFI specification to be published or to just >> not wait at all, but this middle ground matches how we handle the RISC-V >> specifications and it seems like there was broad agreement on it. >> >> As usual with policy stuff I'll wait a bit for others to have a chance >> to chime in, but I think the wording on this one is at least easier to >> reason about than some of the others. >> --- >> Documentation/riscv/patch-acceptance.rst | 8 +++++--- >> 1 file changed, 5 insertions(+), 3 deletions(-) >> >> diff --git a/Documentation/riscv/patch-acceptance.rst b/Documentation/riscv/patch-acceptance.rst >> index 8087718556da..08cb92324eaf 100644 >> --- a/Documentation/riscv/patch-acceptance.rst >> +++ b/Documentation/riscv/patch-acceptance.rst >> @@ -20,9 +20,11 @@ Submit Checklist Addendum >> ------------------------- >> We'll only accept patches for new modules or extensions if the >> specifications for those modules or extensions are listed as being >> -"Frozen" or "Ratified" by the RISC-V Foundation. (Developers may, of >> -course, maintain their own Linux kernel trees that contain code for >> -any draft extensions that they wish.) >> +unlikely to make incompatible changes in the future. For >> +specifications from the RISC-V foundation this means "Frozen" or >> +"Ratified", for the UEFI specifications this means a published ECR. > > It would be good to explicitly mention "UEFI forum specifications" > or > UEFI/ACPI specifications. Ya, "UEFI" is definately wrong. I went with "UEFI forum specifications", I think that's likely the most accurate. > >> +(Developers may, of course, maintain their own Linux kernel trees that >> +contain code for any draft extensions that they wish.) >> >> Additionally, the RISC-V specification allows implementors to create >> their own custom extensions. These custom extensions aren't required >> -- >> 2.34.1 >> >> >> _______________________________________________ >> linux-riscv mailing list >> linux-riscv@lists.infradead.org >> http://lists.infradead.org/mailman/listinfo/linux-riscv > > Other than that, LGTM > > Reviewed-by: Atish Patra <atishp@rivosinc.com>
diff --git a/Documentation/riscv/patch-acceptance.rst b/Documentation/riscv/patch-acceptance.rst index 8087718556da..08cb92324eaf 100644 --- a/Documentation/riscv/patch-acceptance.rst +++ b/Documentation/riscv/patch-acceptance.rst @@ -20,9 +20,11 @@ Submit Checklist Addendum ------------------------- We'll only accept patches for new modules or extensions if the specifications for those modules or extensions are listed as being -"Frozen" or "Ratified" by the RISC-V Foundation. (Developers may, of -course, maintain their own Linux kernel trees that contain code for -any draft extensions that they wish.) +unlikely to make incompatible changes in the future. For +specifications from the RISC-V foundation this means "Frozen" or +"Ratified", for the UEFI specifications this means a published ECR. +(Developers may, of course, maintain their own Linux kernel trees that +contain code for any draft extensions that they wish.) Additionally, the RISC-V specification allows implementors to create their own custom extensions. These custom extensions aren't required
The current patch acceptance policy requires that specifications are approved by the RISC-V foundation, but we rely on external specifications as well. This explicitly calls out the UEFI specifications that we're starting to depend on. Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com> --- This also came up during the Plumbers BoF. The other discussed options were to wait for an ACPI/UEFI specification to be published or to just not wait at all, but this middle ground matches how we handle the RISC-V specifications and it seems like there was broad agreement on it. As usual with policy stuff I'll wait a bit for others to have a chance to chime in, but I think the wording on this one is at least easier to reason about than some of the others. --- Documentation/riscv/patch-acceptance.rst | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-)