Re: [PATCH 2/3] Documentation: RISC-V: Allow patches for non-standard behavior

[Palmer Dabbelt <palmer@rivosinc.com>]

On Tue, 20 Sep 2022 10:19:29 PDT (-0700), Conor Dooley wrote:
> On Tue, Sep 20, 2022 at 07:01:39AM -0700, Palmer Dabbelt wrote:
>> The patch acceptance policy forbids accepting support for non-standard
>> behavior.  This policy was written in order to both steer implementors
>> towards the standards and to avoid
>
> Commit message is cut off here.

Oops, I'll fix it in the v2.

>> So let's just start taking code for vendor-defined extensions.
>
> :)
>
>> Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
>> ---
>> This was discussed at Plumbers, but as with any policy change it's
>> important to make sure everyone has time to chime in.  I intend on
>> letting this sit on the lists for a bit to make sure everyone has a
>> chance to comment, but in practice we're already regularly violating
>> these policies so I'm going to just keep going with the status-quo in
>> the meantime.
>>
>> I'm also still not quite sure how to write down the hardware
>> requirement: the intent is to make this more or less in line with other
>> kernel policies, with the added wrinkle that RISC-V is a bit more
>> distributed than other systems and thus has more core functionality that
>> is vendor-defined.  Hence the need to allow some code to go in earlier
>> than a requirement for publicly-available hardware would allow.
>> ---
>>  Documentation/riscv/patch-acceptance.rst | 10 +++++++---
>>  1 file changed, 7 insertions(+), 3 deletions(-)
>>
>> diff --git a/Documentation/riscv/patch-acceptance.rst b/Documentation/riscv/patch-acceptance.rst
>> index 5da6f9b273d6..8087718556da 100644
>> --- a/Documentation/riscv/patch-acceptance.rst
>> +++ b/Documentation/riscv/patch-acceptance.rst
>> @@ -30,6 +30,10 @@ to go through any review or ratification process by the RISC-V
>>  Foundation.  To avoid the maintenance complexity and potential
>>  performance impact of adding kernel code for implementor-specific
>>  RISC-V extensions, we'll only accept patches for extensions that
>
>> +have been officially frozen or ratified by the RISC-V Foundation, or
>> +for extensions that have been implemented in hardware that is either
>> +widely available or for which a timeline for availability has been
>> +made public.  Hardware that does not meet its published timelines may
>> +have support removed.  (Implementors, may, of course, maintain their
>> +own Linux kernel trees containing code for any custom extensions that
>> +they wish.)
>
> As you know, I was there so I don't disagree with the sentiment of the
> changes & as an employee of a vendor who wants to use a non-standard
> extension I welcome the change.
>
> Only comment I have is that the sentence has gotta kinda long. How about
> a rephrasing/reworking to something like:
> ---8<---
> To avoid the maintenance complexity and potential
> performance impact of adding kernel code for implementor-specific
> RISC-V extensions, we'll only accept patches for extensions that
> either:
>
> - have been officially frozen or ratified by the RISC-V Foundation
> - have been implemented in hardare that is publically available or has
>   a timeline for availability that has been made public
>
> Hardware that does not meet its published timelines may have support
> removed. Implementers, may, of course, maintai their own Linux kernel
> trees containing code for any custom extensions that they wish.
> ---8<---
> I think breaking it up like that highlights the two distinct cases, but
> maybe that's just me.

Seems reasonable, I'm just going to go with roughly that for the v2.

> The o spelling of implementer is in here too.
> Again, am I missing some American English thing there?
>
> I think the bit about the hardware is fair too. Gets the point across
> and if someone's timelines slip all they have to do is publish the new
> timelines...

Ya, that's the idea: we sort of just need to know this stuff is actually 
alive, if there's hardware that's easy but if not then at least getting 
an Ack that there's still some plans for it to show up helps.

> Since my only comments were stylistic (modulo the potentially existing
> spelling mistake) this looks good to me on an idealogical/policy level:
> Reviewed-by: Conor Dooley <conor.dooley@microchip.com>

OK.

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